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SECTION  I 


THE  SYSTEMS  ANALYSIS  PROGPUM 

Various  organizations  have  developed  a number  of  analysis  modules 
which  have  been  directed  toward  the  vulnerability  assessment  of  weapons 
systems  to  nuclear  radiation  effects.  These  efforts  have  been  funded 
by  the  Defense  Nuclear  Agency  over  a span  of  many  years.  Recently, 
attention  has  been  given  to  the  possibility  of  interfacing  these  modules 
into  a comprehensive  systems  analysis  program  for  the  purpose  of  auto- 
matically linking  together  the  various  tasks  which  are  performed  by  the 
separate  modules.  This  report  details  work  accomplished  in  realizing 
certain  compone’"'  s of  the  overall  systems  analysis  program:  the  Executive 

Program,  the  T .jutive  Control  Language,  the  Common  Simulation  Language, 
euid  the  Common  Simulation  Language  Translator.  A companion  report  discusses 
the  Data  Base  Management  System  program  which  is  also  a component  of  the 
systems  analysis  program. 

The  systems  analysis  program  has  been  considered  to  include  the 
following  component  modules:  the  Executive  Program,  the  Data  Base  Manage- 

ment System,  the  CSL  Translator,  the  Topological  Processor,  the  SUPERSAP 
data  base  system,  NELSIM,  SYNAP,  TRAFFIC,  NET-2,  SCEPTRE,  CIRCUS-2,  and 
an  output  processor. 

The  entire  systems  analysis  program  is  controlled  through  the  Executive 
Control  Language.  Individual  modules  are  sequenced  by  the  Executive  Program. 
The  Data  Base  Management  System  is  used  as  a repository  for  input  and  output 
data  files,  problem  descriptions,  parameter  data,  reports,  data  bases,  etc. 

The  number  of  ways  in  which  the  modules  can  interact  is  very  large. 
Figure  1 attempts  to  show  this  interaction  as  a state  diagram;  however, 
entry  and  exit  from  the  state  diagram  can  occur  at  any  node,  and  the 
Executive  Program  and  Data  Base  Management  System  can  interact  along  any 
path  in  the  dia^reun.  SUPERSAP  has  not  been  included  in  the  diagram. 
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Legend;  CS  - CSL  Translator 
C2  - CIRCUS-2 
NL  - NELSIM 
N2  - NET-2 

OP  - Output  Processor 
SC  - SCEPTRE 
SY  - SYNAP 

TP  - Topological  Processor 
TR  - TRAFFIC 


Figure  1,  Interactions  of  Systems  Analysis  Program  Modules 
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The  existing  modules  have  been  developed  over  a period  of  time  with 
no  regard  for  intermodule  compatibility.  Thus,  the  data  formats  and  file 
organizations  which  are  used  at  the  input  and  output  interfaces  for  each 
module  are  generally  incompatible.  It  is  almost  always  necessary  to 
perform  a transformation  on  the  data  output  from  a module  so  that  it  may 
become  acceptable  input  to  another  module.  This  transformation  is  not 
easily  accomplished.  One  approach  is  to  rewrite  the  existing  modules 
using  a standardized  data  format.  Another  approach  involves  storing  the 
data  format  as  part  of  the  data  itself,  with  a data  reformatting  language 
used  to  program  a data  translator  which  then  accomplishes  the  required 
conversion.  A third  approach  involves  the  writing  of  special  data  con- 
version programs  for  each  permissible  module-module  interface;  ignoring 
the  interaction  of  the  Executive  and  Data  Base  Management  System  modules 
it  can  be  seen  from  Figure  1 that  a minimom  of  35  translation  programs 
are  required.  Thus,  data  compatibility  is  a serious  problem  which  must 
be  solved  before  the  projected  systems  analysis  program  can  be  realized. 
It  has  not  been  feasible  to  solve  this  problem  during  the  course  of  the 
investigation. 
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SECTION  II 


EXECUTIVE  PROGRAM  DESIGN 


1.  THE  EXECUTIVE  PROGRAM 

The  Executive  Program  is  responsible  for  the  control  of  the  entire 
systems  analysis  calculation.  It  calls  the  various  application  modules  in 
the  desired  sequence  and  is  responsible  for  handling  files  and  data  required 
as  input  or  generated  as  output  by  the  application  modules.  The  actions  of 
the  Executive  Program  are  controlled  by  a user  supplied  input  deck,  written 
in  the  Executive  Control  Language  (ECL). 

The  Executive  Program  operates  as  a stand  alone  program,  exchanging 
data  with  application  modules  through  system  files.  Similarly,  each  appli- 
cation module  operates  in  a stand  alone  mode.  The  Executive  Program  calls 
application  modules,  with  control  returning  to  the  Executive  following 
completion  of  execution  of  the  called  module.  Successful  incorporation  of 
a module  into  the  overall  structure  does  not  require  any  modification  of  the 
module  itself  other  than  that  which  may  be  desirable  for  passing  information 
between  the  module  and  the  Executive  or  other  modules . 

Operation  of  the  entire  complex  begins  by  a simple  control  card  call 
which  loads  and  executes  the  Executive  Program.  The  Executive  then  reads 
input  cards  which  describe  the  actions  to  be  taken  by  the  Executive  using 
the  Executive  Control  Language.  If  another  module  is  required  to  oerform 
a task  the  Executive  generates  a sequence  of  control  cards  which  load  and 
execute  that  module  (including  any  file  handling  which  might  be  required) 
and  then  recall  the  Ebcecutive.  The  Executive  then  saves  its  current  status 
on  an  executive  storage  area  file  and  calls  an  operating  system  routine 
vrtiich  transfers  control  from  the  normal  control  card  sequence  to  the  control 
card  sequence  which  has  Just  been  created  by  the  Executive.  The  Executive 
then  terminates  its  execution. 

The  operating  system  now  begins  processing  control  cards  from  the 
auxiliary  control  card  file  which  was  Just  created  by  the  Executive.  These 
control  cards  may  specify  any  arbitrary  action,  including  the  loading  and 
execution  of  application  modules.  The  last  control  card  on  the  auxiliary 
file  always  recalls  the  Executive.  The  Executive  retrieves  its  status 
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information  from  the  executive  storage  area  file  and  continues  execution 
where  it  had  left  off,  reading  additional  commands  from  the  ECL  input  deck. 

The  above  process  is  repeated  as  necessary  until  all  steps  in  the 
systems  analysis  problem  have  been  completed.  This  is  signaled  by  a RETURN 
statement  in  the  ECL  input  deck.  At  this  point  the  Executive  calls  an 
operating  system  routine  which  reestablishes  the  original  control  card  file 
and  processing  of  control  cards  from  that  file  is  resumed  at  the  point  where 
it  had  been  interrupted.  Normal  control  card  processing  then  continues  until 
the  end  of  the  Job. 

From  the  above  description  it  can  be  seen  that  the  systems  analysis 
program  complex  consists  of  the  Executive  Program,  a number  of  application 
modules,  files  associated  with  the  Executive  operation,  and  other  files 
associated  with  the  application  modules.  The  Executive  Program  files  are 
l)  the  primary  control  card  file,  2)  the  auxiliary  control  card  file,  created 
by  the  Executive,  3)  the  ECL  input  deck  file,  U)  a procedure  library  per- 
mitting the  user  to  access  ECL  and  control  card  procedures,  5)  the  executive 
storage  area  file  which  saves  the  status  of  the  Executive  when  the  Executive 
is  out  of  core,  and  6)  a system  data  file  which  permits  exchange  of  infor- 
mation on  a word  by  word  basis  between  the  Executive  and  the  application 
modules.  The  entire  systems  analysis  complex  is  depicted  schematically  in 
Fig\ire  2.  The  Executive  Program  concept  can  be  implemented  on  any  computer 
system  which  has  the  ability  to  switch  to  alternate  control  card  streams. 

This  feature  is  available  on  both  IBM  36C/370  and  CDC  6000/7000  series 
computers . 

The  auxiliary  control  card  file  is  created  by  the  executing  FCL  program. 
The  control  card  images  are  embedded  within  the  ECL  program  and  procedures 
called  by  that  program.  This  embedding  is  accomplished  through  specification 
of  a control  card  section  which  contains  the  control  card  images.  Provisions 
are  available  in  ECL  procedures  for  dynsunically  altering  character  strings 
on  the  control  cards.  Whenever  an  ECL  control  card  section  is  encountered 
during  the  execution  of  an  ECL  program,  any  required  string  substitutions 
are  performed,  and  the  entire  control  card  section  is  transmitted  to  the 
auxiliary  control  card  file.  The  Executive  automatically  appends  an 
additional  control  card  at  the  end  of  the  file  which  recalls  the  Focecutive 
Program.  Control  is  then  passed  to  the  auxiliary  control  card  file.  There 
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are  no  restrictions  on  the  control  cards  contained  within  the  control  card 
section,  thus  this  control  technique  is  not  restricted  to  particular  computers 
and  operating  systems. 

The  procedure  library  is  maintained  through  the  ECL.  It  is  a repository 
for  procedures  which  may  be  called  by  the  ECL  main  program  or  from  another 
procedure.  Both  parameter  values  and  character  strings  may  be  passed  when 
a procedure  is  called.  Details  for  procedures  are  discussed  later  under  the 
description  of  ECL. 

The  executive  storage  area  file  is  used  to  store  all  data  associated 
with  a partic’ilar  execution  of  the  Executive  Program  when  the  Executive 
Program  has  relinquished  control  to  the  auxiliary  control  card  file.  During 
this  time  the  Executive  Program  is  not  in  core.  In  order  that  the  Executive 
be  able  to  resume  operation  at  the  point  where  it  was  interrupted  it  must  be 
able  to  save  and  retrieve  all  dynamic  data  using  the  executive  storage  area 
file.  Thus,  data  are  written  to  this  file  just  prior  to  transferring  control 
from  the  Executive  to  the  auxiliary  control  card  file,  and  data  are  read  back 
to  core  when  Executive  Program  operation  is  resumed,  following  exhaustion  of 
the  auxiliary  control  card  file. 

The  system  data  file  is  a special  file  which  permits  the  exchange  of 
information  on  a word  by  word  basis  between  the  Executive  Program  and  the 
application  modules.  It  can  also  be  used  to  exchange  information  directly 
between  application  modules.  Typical  information  included  on  this  file  would 
be  completion  status  of  application  modules,  parameter  values  which  must  be 
passed  from  module  to  module,  etc.  Data  on  this  file  are  stored  using  the 
FORTRAN  namelist  convention  so  that  the  order  in  which  data  appear  is  not 
important.  Data  are  labeled  on  this  file  with  the  data  name  which  permits  a 
free  form  exchange  of  information  between  the  various  modules. 

The  ECL  pennits  the  user  to  specify  arbitrary  names  for  values  and 
strings  generated  and  manipulated  in  the  ECL  program.  These  value  and  string 
variables  are  stored  and  accessed  through  a hash  table  in  the  executive 
storatge  area,  using  the  variable  name  as  the  access  data  for  the  hashing 
mechanism.  Thus,  it  is  eLlways  possible  to  efficiently  access  a variable 
through  its  name.  This  feature  works  very  well  with  the  system  data  file 
which  contains  data  labeled  by  name.  Thus,  the  names  which  are  used  in  the 
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ECL  program  are  global  names  which  can  be  accessed  from  any  part  of  the  ECL 
program,  from  procedures  called  by  the  program,  and,  through  the  system  data 
file,  by  any  application  module. 

When  the  Executive  Program  is  initially  invoked  it  must  read  the  entire 
ECL  input  deck  and  store  this  deck  within  the  executive  storage  area.  This 
is  necessary  for  several  reasons:  l)  all  procedure  library  maintenance 

commands  must  be  processed  and  the  procedure  library  updated  before  execution 
of  the  ECL  program  begins,  2)  all  temporary  procedures  must  be  processed, 

3)  the  ECL  program  and  all  procedures  which  are  called  must  be  compiled, 
and  U)  the  locations  of  all  ECL  statement  labels  must  be  known  prior  to 
execution  to  permit  GO  TO  statements  to  be  properly  handled. 

Compilation  of  the  ECL  program  is  done  internally  by  the  Executive 
Program  and  not  by  an  external  compiler.  The  compiled  program  is  in  the 
form  of  a table  of  operation  triplets,  similar  to  the  internal  intermediate 
form  used  for  representing  programs  by  many  existing  compilers.  However, 
translation  of  the  triplet  table  into  executing  machine  code  is  not  done 
by  the  Executive  Program.  Instead,  an  interpretive  execution  is  employed. 
Although  interpretive  execution  is  slower  than  direct  execution,  it  is 
expected  that  the  principal  contribution  to  computer  time  in  a systems 
analysis  computation  will  be  due  to  the  application  modules.  The  effort 
required  to  produce  a directly  executing  program  does  not  appear  warranted. 

Parsing  and  lexical  analysis  for  the  ECL  input  deck  is  routinely 
accomplished  using  the  LR(k)  parser  and  lexical  analyzer  described  elsewhere 
in  this  report.  The  internal  triplet  table  is  easily  constructed  by  semantic 
routines  which  are  coupled  with  the  parsing  action. 

2.  THE  EXECUTIVE  CONTROL  LANGUAGE 

The  Executive  Control  Language  (ECL)  enables  the  user  to  program  the 
various  steps  of  the  systems  analysis  problem.  The  ECL  controls  the 
operation  of  the  Executive  Program,  which,  in  turn,  invokes  the  application 
modules  which  actually  perform  the  various  systems  euialysls  tasks. 

ECL  consists  of  a subset  of  the  FORTRAN  language  augmented  by  special 
features  which  are  required  for  controlling  the  systems  analysis  program 
complex.  Since  the  Executive  Program  invokes  application  modules  throi:gh 


12 


an  alternate  control  card  stream,  it  is  necessary  to  have  a means  of 
handling  control  card  images  using  ECL.  Thus,  ECL  permits  the  user  to 
embed  control  card  images  within  the  higher  level  ECL  text  stream. 

Futhermoro,  it  is  possible  to  do  character  string  replacement  in  the 
control  card  images,  permitting  dynamic  generation  of  control  cards. 

The  ECL  supports  procediires  through  a procedure  library.  Thus,  ECL 
contains  maintenance  commands  for  entering,  modifying,  deleting,  and  listing 
the  contents  of  the  procedure  library.  Procedures  may  also  be  defined 
without  entry  into  the  library. 

The  systems  analysis  complex  permits  the  exchange  of  data  between  the 
Executive  Program  and  the  application  modules.  Facilities  are  included  in 
ECL  for  managing  data  exchange  for  the  Executive  Program. 

The  elements  of  ECL  are  described  below.  The  ECL  input  deck  may 
consist  of  two  parts:  a procedure  definition  eind  procedure  library  main- 

tenance part,  and  the  main  ECL  program.  Either  part  may  be  omitted;  however, 
if  both  parts  are  present,  the  procedure  definition  aind  procedure  library 
maintenance  part  must  come  first.  The  grammar  for  ECL  is  given  in  Appendix 
N. 

a.  Card  Formatting  Conventions 

The  formatting  rules  of  FORTRAN  are  used  for  all  cards  except  those 
which  are  associated  with  control  card  sections.  The  FORTRAN  formatting 
conventions  are:  comments  are  indicated  by  a "C"  in  column  1,  card  con- 

tinuation is  indicated  by  a nonzero  character  in  column  6,  columns  1-5  are 
reserved  for  an  integer  label  field  (except  on  comment  cards),  and  columns 
7-72  are  used  for  statement  specification.  Columns  73-80  may  contain 
arbitrary  information. 

b.  Data  Types 

Data  may  be  represented  in  ECL  as  real  numbers  or  as  character 
strings.  Real  numbers  are  written  using  a string  of  digits  with  optional 
sign  and  decimal  point,  and  with  an  optional  exponent.  The  plus  sign  is 
optional  for  positive  numbers.  The  decimal  point  is  not  required  if  it 
occurs  to  the  right  of  the  last  magnitude  digit.  The  exponent,  if  used. 
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must  always  follow  immediately  after  the  magnitude  and  begin  with  the  letter 
E.  The  exponent  value  is  expressed  as  a signed  Integer,  representing  a 
power  of  ten,  with  the  plus  sign  optional  for  positive  exponents.  Examples 
of  legal  number  specifications  are: 

25 

+2.3U 

-35.78 

U.E+6 

i»9.789E-3 

65E7 

Strings  may  be  composed  of  any  of  the  keypionch  characters , including 
the  blank,  and  may  be  from  1 to  80  characters  in  length.  The  string  is 
delimited  at  the  beginning  and  end  by  the  $ symbol.  If  it  is  necessary  to 
include  the  $ symbol  as  part  of  the  string,  it  must  be  written  with  a $ 
prefix  symbol  which  acts  as  an  escape  symbol.  Examples  of  strings  are: 

$CAT$ 

$THIS  IS  A STRING. $ 

$123$$ABC$ 

$$$$ 

$/$ 

Both  strings  and  numbers  may  be  represented  symbolically  through  the 
use  of  identifiers.  An  identifier  is  any  alphameric  string,  starting  with 
a letter,  with  a length  of  six  characters  or  less.  Since  all  numbers  are 
represented  as  real  numbers,  there  is  no  integer  significance  associated 
with  identifiers  beginning  with  the  letters  I through  N as  in  FORTRAN. 

c.  Arithmetic  Expressions 

The  user  may  employ  arithmetic  expressions,  involving  the  operators 
♦,  -,  *,  /,  and  **;  these  operators  have  their  normal  FORTRAN  meaning. 
Parentheses  may  be  used  for  grouping  purposes,  with  nesting  permitted  to  any 
level.  Operands  in  arithmetic  expressions  include  identifiers  and  numbers; 
however,  identifiers  which  represent  strings  must  not  be  used  in  arithmetic 
expressions.  The  hierarchy  of  operators  in  arithmetic  evaluation  is  identi- 
cal to  that  of  FORTRAN.  Since  all  quantities  which  enter  into  arithmetic 
expressions  are  real  numbers  there  is  no  data  type  conversion  involved. 
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d.  Logical  Expressions 


ECL  permits  logical  expressions  to  be  constructed  of  any  complexity, 
using  numbers,  identifiers,  arithmetic  expressions,  relational  operators,  and 
logical  operators.  Parentheses  may  be  used  for  grouping  purposes,  with 
nesting  to  any  level  permitted.  The  relational  operators  .EQ.,  .NE.,  .LE. , 
.LT.,  .GE.,  and  .GT.  are  allowed.  The  logical  operators  .AND.,  .OR.,  and 
.NOT.  are  permitted.  Logical  expressions  are  constructed  in  the  same  manner 
as  in  FORTRAN.  Identifiers  which  represent  strings  must  not  be  used  in 
logical  expressions. 

e.  Replacement  Statements 

There  are  two  types  of  replacement  statements  allowed  in  ECL.  The 
most  general  type  is  of  the  form  A = E,  where  E is  an  arithmetic  expression 
and  A is  any  identifier.  The  other  type  is  of  the  form  A = S,  where  S is  a 
string  or  an  identifier  representing  a string,  and  A is  any  identifier;  A 
will  represent  a string  following  the  replacement  operation  of  the  second 
type. 

f.  Control  Statements 

Unconditional  branches  to  a specified  label  are  made  as  follows; 

GO  TO  n 

where  n is  an  ECL  label. 

The  logical  IF  is  available  for  conditional  execution  of  a statement. 

It  has  the  form: 

IF(L)  s 

where  L is  a logical  expression  and  s is  any  ECL  statement  except  another 
logical  IF.  If  the  logical  expression  is  true,  then  statement  s is  executed, 
otherwise  statement  s is  skipped  eind  the  next  ECL  statement  is  executed. 

The  CONTINUE  statement  is  available.  It  is  a do-nothing  statement  and 
control  is  always  passed  to  the  next  statement.  It  is  useful  when  control 
must  be  passed  to  the  start  of  a control  card  section;  since  labels  cannot 
be  attached  to  the  start  of  the  control  card  section,  a labeled  CONTINUE 
statement  may  be  used  Just  sdiead  of  the  control  card  section  for  this  purpose. 
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The  RETURN  statement  is  used  for  return  of  control  from  a called  pro- 
cedure back  to  the  calling  routine.  If  a RETURN  occurs  in  the  main  ECL 
program,  control  is  passed  back  to  the  primary  control  card  file. 

g.  Procedures 

The  user  may  specify  procedures  using  ECL.  A procedure  may  be 
catalogued  in  the  procedure  library  or  it  may  be  specified  as  a local 
procedure,  accessible  only  to  the  ECL  input  deck  in  which  it  is  specified. 

A procedure  may  be  defined  with  or  without  a list  of  formal  parameters. 
Formal  parameters  are  used  to  pass  numerical  values  and  strings  from  the 
calling  program  to  the  procedure.  In  addition,  numerical  values  may  be 
returned  to  the  calling  program  using  formal  parameters.  Procedures  which 
utilize  formal  parameters  are  written  in  terms  of  the  formal  parameters. 

Since  procedures  may  call  other  procedures , a formal  parameter  may  be  passed 
through  several  levels  of  procedure  calls . 

Procedures  are  defined  in  the  procedure  definition  and  procedure  library 
maintenance  part  of  the  deck  and  must  precede  the  main  ECL  program.  The  first 
card  of  the  procedure  definition  has  one  of  four  forms: 

DEFINE,  procname 

DEFINE,  procname (parameterlist ) 

STORE,  procname 

STORE,  procname ( parameterlist ) 

where  the  keyword  DEFINE  indicates  that  the  procedure  is  locally  defined  and 
is  not  to  be  entered  into  the  procedure  library,  and  the  keyword  STORE 
indicates  that  the  procedure  is  globally  defined  and  is  to  be  entered  into 
the  procedure  library.  If  a procedure  is  locally  defined  and  a procedxire 
with  the  same  name  already  exists  in  the  library,  the  locally  defined  pro- 
cedure will  be  used  by  the  ECL  program.  If  a procedxire  is  globally  defined 
and  a procedure  with  the  same  name  already  exists  in  the  library,  the  new 
procedure  will  replace  the  old  procedure  in  the  library. 

The  procname  field  specifies  the  procedure  name.  Procedure  names  are 
composed  of  one  to  six  letters.  The  parameterlist  field  is  the  list  of 
formal  parameters  used  in  the  procedure.  These  parameters  are  of  two  types: 
value  type  and  string  type.  Both  types  may  be  passed  as  parameters  in  a 
procedure  call  within  the  procedure  being  defined.  Formal  parameters  are 
separated  by  commas. 
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Value  type  formal  parameters  are  represented  by  identifiers.  String 
type  formal  parameters  are  represented  by  identifiers  delimited  by  $ symbols. 
Thus,  an  example  of  the  first  line  of  a procedure  definition  is; 

STORE , ANALYZ ( TIME , FREQ , $TAPE?$ , $ABC  $ , ERROR ) 

A procedure  may  contain  two  kinds  of  cards.  ECL  cards  contain  state- 
ments in  the  ECL  lainguage.  The  other  kind  of  card  is  a control  card.  Value 
type  formal  parameters  may  not  be  used  in  connection  with  control  cards; 
conversely,  string  type  formal  parameters  may  only  be  used  in  connection 
with  control  cards.  If  a character  string  corresponding  to  a formal 
parameter  of  the  value  type  appears  on  a control  card,  no  action  involving 
the  formal  parameter  will  be  taJcen.  Similarly,  if  a character  string 
corresponding  to  a formal  parameter  of  the  string  type  occurs  on  an  ECL 
card,  no  action  involving  the  formal  parameter  will  be  taken. 

A procedure  may  be  written  using  only  ECL  statement  types  which  may 
appear  in  the  main  ECL  program.  Thus,  DEFINE,  STORE,  DELETE,  and  LIST 
statements  may  not  appear  within  a procedure. 

A procedure  is  referenced  using  the  CALL  statement; 

CALL  procname 

CALL  procname  ( ar gximent  list) 

where  procname  is  the  procedure  name,  and  argumentlist  is  a list  of  argu- 
ments representing  values  and  strings  in  one-to-one  correspondence  with 
the  formal  parameters  in  the  procedure  definition.  Arguments  are  separated 
by  commas.  Strings  may  be  represented  by  an  actual  string,  enclosed  in  $ 
symbols,  or  by  an  identifier  representing  a string.  Values  may  be  repre- 
sented by  arithmetic  expressions,  by  an  identifier  representing  a value, 
or  by  a number.  For  example: 

CALL  ANALYZ , AFC /2 . 5+BI AS , FILE3U , $REWIND$ , FLAG ) 

In  this  example  (which  corresponds  to  the  procedure  definition  example  above) 
the  first,  second,  emd  fifth  argioments  are  values,  while  the  third  and 
fourth  arguments  are  strings. 


IT 


A procedure  definition  is  terminated  by: 
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END  procname 

where  procname  is  the  name  of  the  procedure  being  defined, 
h.  Data  Communication  Statements 

The  Executive  Program  utilizes  the  system  data  file  to  communicate 
data  between  itself  and  the  application  modules.  Thus,  data  may  be  written 
onto  this  file  by  the  Executive  Program  to  be  read  by  a particular  applica- 
tion module,  and  conversely  an  application  module  may  write  data  on  the  file 
to  be  read  by  the  Executive  Program.  Since  data  is  written  using  the  FORTRAN 
namelist  format,  it  is  not  necessary  that  a particular  order  be  observed  on 
the  file.  The  system  data  file  can  be  regarded  as  a labeled  data  base  of 
variable  size. 

ECL  has  two  statements  to  permit  the  user  to  interact  with  the  system 
data  file.  The  file  is  always  rewound  before  either  statement  is  executed. 
Thus,  old  information  is  always  lost  from  the  file  when  an  ECL  WRITE 
statement  is  executed. 

The  WRITE  statement  has  the  format: 

WRITE(valuelist) 

where  valuelist  is  a list  of  identifiers  whose  values  are  to  be  written 
to  the  file.  Identifiers  in  the  list  are  separated  by  commas.  Since  both 
the  identifier  name  and  the  identifier  value  are  written  to  the  file,  it 
is  seen  that  nxmibers,  strings,  and  arithmetic  expressions  cannot  be  included 
in  the  valuelist  field.  An  example  of  a WRITE  statement  is: 

WRITE ( TIME , FREQ , ERROR ) 

The  system  data  file  may  be  read  by  using  the  READ  statement: 

READ 

There  are  no  other  parameters  involved  with  the  READ  statement  since  all 
information  is  contained  on  the  system  data  file.  If  a value  is  read  for 
an  identifier  already  in  the  executive  storage  area,  the  old  value  is 
replaced  by  the  new  value.  If  the  identifier  is  not  already  resident  in 
the  executive  storage  area,  a space  is  created  for  it  and  the  value  is 
stored. 
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i.  Control  Card  Sections 


The  user  may  declare  control  card  sections  within  both  the  main  ECL 
program  and  in  procedures.  This  is  the  means  by  which  control  cards  are 
entered  into  the  Executive  Program  system.  In  fact,  a procedure  could 
contain  only  control  card  sections.  As  many  control  card  sections  may  be 
declared  as  needed. 

When  the  ECL  program  is  executed  and  a control  card  section  is  encoun- 
tered, any  specified  string  replacements  are  made  to  the  control  card  images. 
Then  all  control  cards  in  that  section  are  queued  onto  the  auxiliary  control 
card  file,  control  is  relinquished  by  the  Executive  Program,  and  the  operating 
system  begins  processing  control  cards  from  the  a’oxiliary  file.  The  last 
control  card  on  the  file  is  automatically  added  by  the  Executive  Program 
when  the  file  is  created,  and  it  returns  control  back  to  the  Executive 
Program  which  then  resumes  ECL  processing  following  the  control  card  section 
which  caused  the  interruption. 

Thus,  control  card  sections  may  contain  arbitrary  card  images  and  have 
provisions  for  dynamic  modification  through  string  type  formal  parameters 
whenever  they  appear  in  a procedure. 

The  control  card  section  is  introduced  by: 

/CC/ 

This  is  followed  by  one  or  more  control  cards.  The  section  ie  terminated  by: 
/ENDCC/ 

String  type  formal  parameters  must  appear  in  the  control  card  images 
exactly  as  they  appear  in  the  formal  parameter  list  in  the  procedure 
definition,  i.e,,  they  are  identifiers  enclosed  by  $ symbols.  Since  the 
identifier  may  be  arbitrary  it  is  easy  to  choose  identifiers  which  do  not 
conflict  with  control  card  constructs  of  the  same  form  for  which  string 
replacement  is  not  intended.  When  the  string  replacement  occurs,  the  width 
of  the  replaced  field  agrees  with  the  length  of  the  string  in  the  procedure 
call  (not  counting  the  $ symbols),  not  with  the  width  of  the  formal  parameter 
name.  Thus,  characters  on  the  control  card  following  the  replacement 
operation  may  be  shifted  left  or  right  from  their  original  positions. 
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J . Procedure  Library  Maintenance 

Facilities  are  available  in  ECL  for  maintaining  the  procedure  library. 
All  library  maintenance  cards  must  occur  as  the  fii'st  cards  in  the  ECL  input 
deck. 

A procedure  may  be  stored  into  the  procedure  library  by  using  a STORE 
statement  followed  by  the  procedure  definition.  If  a procedure  with  the 
same  name  previously  existed  in  the  library  it  is  replaced  with  the  new 
procedure. 

A procedure  in  the  library  can  be  deleted  using  the  DELETE  feature: 
DELETE , procname 

where  procname  is  the  procedure  name. 

A contents  of  the  procedure  libraiT"  can  be  listed  by  including  the 

card ; 

LIST 

k.  END  Card 

The  ECL  input  deck  Is  terminated  with  the  card; 


END 


SECTION  III 


THE  COMMON  SIMULATION  LANGUAGE 


1.  GENERAL 

a.  Character  Set 

The  Common  Sirjulation  Language  is  composed  of  a character  set 
which  is  used  to  construct  the  keywords,  identifiers,  delimiters,  and 
other  elements  of  the  language.  The  characters  used  are  the  numerical 
characters  0 through  9,  the  alphabetic  characters  A through  Z,  and  the 
special  characters  ()+*/.,$-  and  =.  The  blank  may  be  used  optionally 
but  is  not  required  by  the  language. 

b.  Basic  Language  Structure 

The  language  is  free  form  in  structure.  Information  is  conveyed 
in  the  language  through  a series  of  entries  which  are  punched  on  cards. 

An  entry  may  consist  of  a single  card  such  as  would  be  used  to  specify  a 
built-in  network  element.  Certain  entries  require  several  cards  and  may 
include  other  entries  as  subentries.  Such  multiple  card  entries  must 
always  be  terminated  with  a card  containing  the  word  END.  The  END  card 
normally  terminates  only  the  most  recently  introduced  unterminated  entry. 

It  is  possible  to  terminate  several  entries  simultaneously  by  using  the 
word  END  followed  by  an  appropriate  key  word.  This  will  terminate  all 
entries  up  to  and  includin,:  the  most  recently  introduced  unteminated 
entry  which  was  initiated  by  that  keyword. 

The  final  card  in  a CSL  deck  is  one  of  the  following  two  cards: 

END 

END  DECK 

where  the  END  DECK  card  may  be  used  to  terminate  all  previously  unterminated 
entries . 
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Although  the  language  structure  is  hierarchical  due  to  the  permissible 
nesting  of  entries,  an  indented  structure  is  not  required  to  delimit  the 
extent  of  the  various  entries;  this  is  accomplished  by  the  END  card.  However, 
examples  given  in  this  report  will  be  displayed  in  indented  form  to  visually 
indicate  the  relationships  between  the  various  sections. 

The  order  of  entries  is  arbitrary  except  where  a particular  execution 
sequence  must  be  specified. 

Throughout  this  description  of  CSL  there  will  be  references  made  to 
global  and  local  definitions,  and  to  main  network,  description  notation. 

A global  definition  is  a definition  which  is  made  on  the  outermost  hier- 
archical level,  i.e.,  it  is  made  through  an  entry  which  is  not  contained 
inside  of  another  entry.  A definition  which  is  contained  within  the  context 
of  another  entry  is  a local  definition;  it  applies  only  within  the  entry 
which  contains  it,  and  to  any  entries  nested  inside  of  that  entry  unless 
they,  in  turn,  contain  an  even  more  local  definition  of  the  same  quantity. 

I Thus,  the  most  local  definition  of  a quantity  always  applies,  and  a defini- 

tion never  applies  outside  of  the  entry  which  contains  that  definition.  In 
the  absence  of  any  local  definition,  the  global  definition  applies;  if  the 
global  definition  is  not  present,  a default  definition  may  apply. 

Since  the  network  may  be  built  up  from  nested  subnetworks,  there  are 
usually  several  names  which  may  be  used  to  refer  to  a quantity  which  resides 
in  the  innermost  nest,  depending  upon  the  nest  level  from  which  the  reference 
is  made.  The  main  network  description  notation  refers  to  the  name  which  must 
be  used  to  make  the  reference  from  the  outermost  level,  i.e.,  t}iat  level 
which  contains  all  nests. 

c.  Card  Punching  Conventions 

Cards  are  punched  in  free  format,  beginning  with  any  column.  The 
language  is  free  form  in  structure.  The  blank  may  be  used  as  an  optional 
character  which  is  ignored  except  when  it  occurs  in  the  text  of  a comment. 
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Punching  on  a card  may  begin  in  any  arbitrary  column  for  all  entries. 
Continuation  from  one  card  to  the  next  is  accomplished  by  punching  any 
of  the  characters  +-,/(  or  = as  the  last  non-blank  character  on  the  card 
to  be  continued  (this  rule  does  not  apply  to  comment  cards). 

d.  Comment  Cards 

Comment  cards  always  start  with  the  character  $ and  cannot  be  con- 
tinued from  one  card  to  the  next.  A comment  card  may  contain  arbitrary 
text.  As  many  comment  cards  as  desired  may  be  included  in  the  deck  and 
they  may  be  arbitrarily  inserted.  Embedded  blanks  in  comment  cards  will 
be  preserved. 

Coimnents  may  occur  at  any  point  in  the  CSL  input  deck  except  within 
the  body  of  a procedure  definition,  table  definition,  or  curve  definition. 

e.  Text  Definition 

A group  of  cards  containing  arbitrary  information  may  be  assigned 
a symbolic  name  and  then  used  freely  at  any  point.  The  text  definition 
is  accomplished  in  the  following  manner: 

TEXTn 

(One  or  more  cards  which  comprise  the  text  which  is  being  defined) 

END  TEXT 

TEXTn  is  the  symbolic  name  of  the  group  of  cards  which  follow,  where  n is 
an  integer.  The  card  group  is  terminated  by  and  does  not  include  the 
ENDTEXT  card.  The  card  group  may  include  any  entry,  including  any  asso- 
ciated END  card,  except  ENDDECK  eind  other  text  definitions.  A text 
definition  must  precede  any  reference  to  that  definition  in  the  card  deck. 

Text  definitions  are  referenced  by: 

USE  TEXTn 
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An  example  of  text,  definition  is  given  by: 


■ 


TEXT  3 

R3,U-7=1.5 
c6,3-T=.009 
USE  TEXT? 

RU, 2-5=7. 8 
END  TEXT 
TEXT? 

C12,5-8=.003 
RU5,2-5=6.5 
END  TEXT 

Consider  the  following  excerpt  using  the  above  definitions: 

Rl*3,K-L=7 
USE  TEXT3 
C?6  ,F-G=12 

This  excerpt  is  equivalent  to: 

Rl4  3,K-L=7 
R3,U-7=1.5 
C6,3-7=.009 
C12,5-8=.003 
RJ45,2-5=6.5 
R1+,2-5=7.8 
C?6  ,F-G=12 

A text  definitio.i  may  be  referenced  as  many  times  as  desired.  Text 
references  may  be  nested  as  shown  in  the  above  example. 

A USETEXT  card  may  occur  at  any  point  in  the  CSL  input  deck  after 
the  corresponding  text  has  been  defined  except  within  the  body  of  a pro- 
cedure definition,  table  definition,  or  curve  definition. 

2.  NETWORK  DESCRIPTION 

a.  Node  Names 

i Network  node  names  are  composed  of  any  arbitrary  sequence  of  the 

alphabetic  characters  and  the  digits.  The  name  may  be  of  any  length,  pro- 
vided that  continuation  from  one  card  to  the  next  is  not  required. 
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The  digit  0 is  reserved  as  the  node  name  for  the  datum  node;  the 
user  may  also  specify  additional  nodes  as  the  datum  node  by  including 
a DATUM  card.  For  example,  to  specify  the  node  GND  as  the  datum  node, 
include  the  card: 

DA'TUM,GND 

b.  Element  Specification 

There  are  two  kinds  of  network  elements:  elements  which  are  built 

into  the  simulation  module  and  elements  which  are  defined  by  the  user  in 
terms  of  the  built-in  elements  and  other  user  defined  elements.  The  user 
defined  elements  are  called  subnetworks  in  this  report. 

The  general  format  for  element  specification  consists  of  three  fields 
in  the  following  order:  the  element  name,  the  network  nodes  to  which  the 

element  is  connected,  and  the  element  parameter  value(s)  specification. 

The  last  two  fields  are  optional.  The  format  can  be  expressed  as  follows: 

Elname ,Nodes=Values 

The  Elname  field  specifies  the  element  name,  consisting  of  a prefix 
composed  only  of  alphabetic  characters  followed  by  an  alphameric  suffix. 

The  prefix  specifies  the  kind  of  element.  The  suffix  must  always  begin 
with  a digit. 

The  Nodes  field  is  separated  from  the  Elname  field  by  a comma  and 
specifies  the  names  of  the  network  nodes  to  which  the  element  is  to  be 
connected.  It  is  permissible  to  use  the  character  / as  a prefix  for  a 
node  name  to  denote  optiontil  properties  associated  with  that  node  for 
certain  elements.  The  - character  is  used  as  a delimiter  between  node 
names.  If  the  element  is  a system  element,  the  first  nodes  listed  are 
the  output  nodes.  The  Values  field  begins  with  the  = character  and  con- 
tains one  or  more  parameter  values  associated  with  the  element  specification. 
Multiple  values  are  separated  by  commas.  Default  values  are  available  in 
the  language  processing  module  so  that  missing  veilues  may  be  automatically 
supplied  using  the  default  values. 
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Character  strings  are  permitted  as  values  for  specific  elements. 

Each  character  string  must  begin  with  an  alphabetic  character  and  contain 
only  alphameric  characters. 

All  built-in  elements  have  a parameter  symbol  associated  with  each 
value.  This  permits  an  alternate  method  cf  describing  such  elements. 

The  alternate  format  permits  selected  parameter  values  to  be  specified, 
the  missing  values  assuming  their  default  values.  The  alternate  format 
is : 

Elname , Nodes , (Valuelist ) 

where  Valuelist  is  enclosed  by  parentheses  and  consists  of  one  or  more 
value  entries,  separated  by  commas.  Each  value  entry  consists  of  the 
parameter  symbol,  an  equal  sign,  and  the  value  of  the  parameter. 

For  example,  a core  winding  element  may  require  specification  of  both 
the  winding  resistance  and  the  number  of  turns;  let  these  values  be  asso- 
ciated with  the  parameter  symbols  R and  N,  respectively.  Such  an  element 
can  be  described  in  the  alternate  format  by: 

CWi+5,U-6,(N=10,R=.00l) 

The  standard  element  description  format  could  also  be  used,  except 
that  the  parameter  values  must  be  listed  in  the  proper  sequence  (in  this 
case  R followed  by  N ) : 

CWU5,U-6=.001,10 

This  description  of  CSL  does  not  explicity  describe  the  network  elements 
which  may  be  included  in  the  CSL  language.  The  form  of  CSL  is  such  that  an 
unlimited  number  of  network  element  types  can  be  used  with  the  language, 
with  arbitrary  prefixes , numbers  of  nodes , numbers  of  values , and  arbitrary 
parameter  names.  Thus,  the  choice  of  network  elements  and  their  specifica- 
tion in  CSL  depends  upon  a particular  implementation  of  CSL  eind  not  on  the 
CSL  language  in  general.  However,  voltage  and  current  sources  are  briefly 
described  in  the  following  section  because  of  their  use  of  complex  notation, 
a general  feature  of  CSL. 
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(l)  Voltage  and  Current  Sources 

A voltage  and  current  source  may  be  specified  as  either  a 
real  source  or  a complex  source.  A real  source  is  used  to  drive  the  large 
signal  DC  and  transient  solutions;  during  the  frequency  domain  solution  it 
appears  as  a short  circuit  for  a voltage  source  and  an  open  circuit  for  a 
current  source.  A complex  source  is  used  to  provide  sinusoidal  excitation 
for  a linear  frequency  domain  solution;  during  the  large  signal  solution 
and  during  the  two  port  small  signal  transfer  function  calculations  it 
appears  as  a short  circuit  for  a voltage  source  and  an  open  circuit  for 
a current  source. 

A real  source  is  described  using  the  normal  element  description 
format : 

E56,G-M=3.8 

A complex  source  requires  two  values  to  describe  it . The  two  values 
are  separated  by  a comma  and  the  value  pair  must  be  enclosed  by  paren- 
theses. One  of  the  words  C0MPLEX,  RADIANS,  or  DEGREES  may  optionally 
precede  the  parenthesized  pair.  For  example: 

J78 , B-U=C0MPLEX ( U , 8 ) 

JT8 , B-U=RADIANS (5,1.2) 

J78 ,B-U=DEGREES( 5 ,65 ) 

J78,B-U=(5,65) 

If  the  word  C0MPLEX  appears,  the  first  value  is  the  real  component, 
the  second  value  is  the  imaginary  component.  If  the  word  RADIANS  appears, 
the  first  value  is  the  magnitude,  the  second  value  is  the  phase  angle  in 
radians.  If  the  word  DEGREES  appears,  or  if  no  word  appears,  the  first 
value  is  the  magnitude,  the  second  value  is  the  phase  angle  in  degrees. 

c.  Subnetwork  Definition 

The  user  may  define  subnetworks  which  are  composed  of  built-in 
elements  and/or  other  subnetworks.  Thus,  it  is  possible  to  nest  subnetworks. 
The  format  for  subnetwork  definition  is  identical  to  that  for  element  speci- 
fication except  that  SUBNET  is  used  as  a keyword  ahead  of  the  name  field, 
the  name  field  contains  only  the  prefix,  and  dummy  node  and  formal  parameter 
names  are  used. 
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The  subnetwork  prefix  must  contain  only  letters  and  must  not  conflict 
with  any  other  defined  name  which  may  start  an  entry.  The  formal  parameter 
names  are  composed  of  alphameric  characters  and  must  begin  with  a letter. 

The  formal  parameter  names  must  not  conflict  with  any  other  defined  name 
which  can  be  referenced  in  a mathematical  expression. 

When  formal  parameter  names  are  replaced  during  subnetwork  references 
a character  string  replacement  occurs.  Thus,  both  values  and  character 
strings  can  be  passed  as  formal  parameters.  Although  only  alphameric 
formal  parameter  names  are  permitted,  the  corresponding  character  string 
in  the  referencing  expression  is  practically  unlimited. 

Subnetwork  definitions  may  include  element  references,  subnetwork 
references,  subnetwork  definitions,  function  definitions,  table  definitions, 
procedure  definitions,  datum  node  definitions,  real  variable  definitions, 
and  USETEXT  entries.  All  definitions  apply  only  to  the  subnetwork  being 
defined  and  any  subnetwork  which  is  contained  within  that  subnetwork, 
unless  more  local  definitions  are  !aade  within  those  descendant  subnetworks. 
Each  subnetwork  definition  is  concluded  with  an  END  SUBNET  card. 

An  example  of  a subnetwork  definition  is: 

SUBNET ,TR ,J-K-L=A , BC 
LCB1,J-5=BC 
LCB2,5-3=BC 
C1,3-L=A 
Rl,5-L=2 
R2,K-5=100 

F9(R)=R**2»EXP(-ABS(R/50))+35 
SUBNET, LCB,1-3*BC 
LCA1,1-2=BC 
LCA2,2-3=BC 
END  SUBNET 
SUBNET, LCA,A-C=BC 

C 1 , B-0*TABLE3 ( BC ( TIME ) ) 

C2,C-0«5.6TE3 
END  SUBNET 

L1,A-B»F9(LCB1.LCA2.C1) 

L2,B-C»U5.8 

TABLE3 

0,20 

5,25 

10.35 

15.36 

END  SUBNET 
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This  example  illustrates  the  nesting  concept.  Subnets  LCAl  and  LCA2 
are  nested  inside  of  subnet  LCB,  and  subnets  LCBl  and  LCB2  are  nested 
inside  of  subnet  TR.  A reference  to  any  nested  value,  node,  function, 
table,  real  variable,  or  procedure  can  be  made  from  any  higher  nest  level 
by  constructing  a compound  name  which  traces  the  nesting  process,  using 
the  dot  as  a separator  between  nest  levels.  Thus,  in  subnet  TR  the  value 
field  of  inductor  LI  references  the  capacitor  Cl  which  is  contained  in 
subnet  LCA2  which  is  contained  in  subnet  LCBl;  this  is  done  by  using 
I€B1.LCA2.C1  as  the  capacitor  name. 

If  a datum  node  name  0 appears,  it  will  be  treated  as  being  the 
global  datum  node. 

A subnet  may  be  used  in  the  network  simply  by  describing  it  as  an 
ordinary  network  element.  Using  the  subnet  TR  as  an  example: 

TR2 , 1- 3-0=TIME , SQRT 
TR5  ,2-T-6=TIME*«2 ,L0G 

d.  Model  Definition 

CSL  permits  the  user  to  define  models  which  may  be  stored  in  a 
model  library.  ITie  model  may  only  be  defined  globally  and  must  not  contain 
references  to  other  models.  A model  definition  is  introduced  by  a card 
which  contains  the  keyword  MODEL,  the  model  prefix  name,  the  external  dummy 
node  names,  and  the  model  parameter  names.  This  is  followed  by  additional 
cards  which  define  the  model  in  terms  of  other  CSL  entries.  The  model 
definition  may  include  element  references,  subnetwork  definitions  and 
references,  fxinction  definitions,  table  definitions,  procedure  definitions, 
datum  node  definitions,  and  real  variable  definitions.  The  model  concludes 
with  an  EOT)  MODEL  card. 

The  model  prefix  must  contain  only  letters  and  must  not  conflict  with 
any  other  defined  name  which  can  start  an  entry.  The  model  parameter  names 
are  composed  of  alphameric  characters  and  must  begin  with  a letter.  The 
parameter  names  must  not  conflict  with  any  other  defined  name  which  can  be 
referenced  in  a mathematical  expression. 
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An  example  of  a model  definition  is: 


M(2DEL  ,DI0DE  ,1-2=RB , IS ,TH ,GC  ,W,C  ,VZ  ,N 
J1,3-2=IS*(EXP(TH*V.J1)-1) 

C1,3-2=C/(1-V(C1)/VZ)»*N+TH»(J1+IS)/W) 

R1,1-3=RB 

R2,3-2=RC 

DEFAULT (RB= . 001 , IS=lE-8 ) 

END  M(?DEL 

The  model  de*'inition  may  include  a set  of  default  numerical  values 
for  the  model  parameters.  This  is  done  with  the  DEFAULT  card  as  shown  in 
the  above  statement.  All  values  which  are  not  assigned  specific  default 
values  automatically  assume  a default  value  of  zero.  Alternatively,  the 
DEFAULT  values  may  be  listed  without  the  parameter  names,  using  the  same 
order  as  the  parameter  names  are  specified  on  the  MODEL  card: 

DEFAULT= . 001 ,lE-8  ,0 ,0 ,0 ,0  ,0 ,0 

A model  may  be  assigned  a set  of  parameter  values  by  means  of  a DEVICE 
entry.  These  parameter  values  are  assigned  a device  name,  permitting  the 
parameter  set  to  be  referenced  by  the  device  name.  All  parameters  which 
are  not  assigned  specific  values  through  the  DEVICE  entry  will  remain  at 
the  default  values  for  the  model  with  which  the  parameters  are  associated. 
The  DEVICE  entry  occurs  globally  and  lists  the  keyword  DEVICE,  the  alpha- 
meric name  to  be  assigned  to  the  parameter  set,  the  model  prefix,  and  the 
parameter  values.  For  example: 

DEVICE , 1N91U ,DI0DE= . 001 ,lE-9 ,30 ,1E10 , . 7 ,3 ,1 , . 5 

Here  the  parameter  values  are  in  the  same  sequence  as  the  parameter 
names  are  listed  on  the  MODEL  card.  If  some  other  order  is  desired,  or  if 
only  certain  parameter  values  are  to  be  specified,  the  alternate  value 
format  may  be  used  in  which  the  pareimeter  names  are  specified: 

DEVICE , 1N91U ,DI0DE(TH=3O ,W= . 7 ,RB= . 001 ) 


30 


A model  may  be  incorporated  into  the  network  description  on  any 
hierarchical  level.  This  is  done  by  considering  it  to  be  a standard 
element,  using  the  model  prefix  followed  by  an  alphameric  suffix  which 
begins  with  a digit.  The  value  field  specifies  the  name  which  has  been 
assigned  to  the  parameter  set  for  the  model;  if  no  parameter  set  has  been 
specified,  the  value  field  is  not  used.  For  example: 

DI(^DE1,56-A=1N91U 

SENS(2R12,A-B 

3.  fiATHEMATICAL  NOTATION 

a.  Values 

A value  may  be  specified  by  either  a number  or  a mathematical 
expression. 

b.  Numbers 

Numbers  may  be  written  with  optional  magnitude  sign,  exponent  sign, 
exponent,  and  decimal  point.  The  exponent  portion,  if  used,  is  introduced 
with  the  character  E.  Examples  are: 

25 

+2.3U 

-35.78 

U.E+6 

U9.T89E-3 

65E7 

c.  Mathematical  Expressions 

Mathematical  expressions  may  be  constructed  using  the  rules  of 
FORTRAN  to  represent  values.  A mathematical  expression  may  be  constructed 
using  numbers,  element  parameter  values,  global  variables,  real  variables, 
response  variables,  user  functions,  procedures,  tables,  and  mathematical 
functions . 
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d.  Element  Parameter  Values 


All  built-in  element  parameter  values  may  be  referenced.  If  the 
element  has  only  a single  parajneter  value,  the  value  is  referenced  by 
simply  using  the  element  name.  If  the  element  has  multiple  parameter 
values,  a particiilar  parameter  value  may  be  referenced  by  constructing  a 
compound  name  consisting  of  the  element  name,  a dot,  and  the  symbol  for 
the  parameter  of  interest  (if  only  the  element  name  is  given,  the  value  of 
the  first  parameter  in  the  standard  parameter  order  will  be  obtained^.  For 
example : 

R3  gives  the  resistance  value  of  resistor  R3 

CW6.R  gives  the  resistance  value  of  core  winding  CW6 

CW6.N  gives  the  number  of  turns  for  core  winding  CW6 

CW6  gives  the  resistance  value  of  core  winding  CW6  (by  default) 

e.  Global  Variables 

Certain  names  are  reserved  for  global  variables,  have  global  meaning, 
and  may  be  used  as  desired.  Examples  are  TIME  and  FREQ  for  the  time  and 
frequency  variables. 

f.  Real  Variables 

The  user  may  define  real  variables  using  names  which  do  not  conflict 
with  reserved  names  in  the  language.  The  definition  is  accomplished  by  a 
mathematical  equation  where  the  left  side  is  the  real  variable  name  being 
defined  and  the  right  side  is  a mathematical  expression.  All  arithmetic 
is  performed  with  real  numbers.  An  example  is: 

F0RCE=M»A 

Real  variable  names  are  composed  of  alphameric  characters  and  must 
begin  with  a letter.  The  names  must  not  conflict  with  any  other  defined 
name  which  may  start  an  entry  or  be  referenced  in  a mathematical  expression, 
or  the  keywords  OBJ,  LINLOG,  LOGLIN,  LOGLOG,  POLAR,  NYQUIST,  and  FINAL. 
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g.  User  Functions 


The  user  may  define  functions  which  include  an  argument  list 
containing  formal  parameter  names.  The  right  hand  side  of  the  function 
definition  is  a mathematical  expression  of  any  complexity  which  is  written 
in  terms  of  the  formal  parameter  names,  other  quantities,  and  other  functions 
as  desired.  The  function  reference  specifies  the  quantities  which  are  to 
replace  the  formal  parameter  names  during  the  computation  of  the  function 
value . 

Function  names  are  composed  of  alphameric  characters  and  must  begin 
with  a letter.  The  names  must  not  conflict  with  any  of  the  standard 
mathematical  functions  available  in  CSL,  the  keywords  COMPLEX,  RADIANS, 
or  DEGREES,  or  any  of  the  special  functions  and  modifiers  available  in 
CSL,  namely,  SENS,  PT,  PV,  IV,  D,  S,  Q,  E,  F,  N,  A,  B,  Y,  Z,  I,  V,  U,  and 
P. 

The  formal  parameter  names  are  composed  of  alphameric  characters  and 
must  begin  with  a letter.  The  names  must  not  conflict  with  any  other 
defined  name  which  can  be  referenced  in  a mathematical  expression. 

An  example  of  a function  definition  is: 

F56 (A , B ,C )=A»C0S (ANGLE )+B/TIME+C 

This  function  may  then  be  referenced  as  in  this  example: 
C23,6-9=F56(3,N(3),F2(TABLE2(X13/I(C5)))) 
h.  Procedures 

The  user  may  specify  modules  of  FORTRAN  code  called  procedures 
as  part  of  the  network  description  text.  A procedure  is  introduced  by  a 
card  containing  the  word  PROCEDURE  and  the  procedure  name,  followed  by 
one  or  more  formal  parameters.  This  is  followed  by  the  text  of  the  pro- 
cedure. The  value  of  the  procedure  is  specified  by  a replacement  statement 
which  has  the  procedure  name  on  the  left  side.  Control  is  returned  to  the 
calling  expression  by  the  RETURN  card.  The  procedure  concludes  with  an  END 
card. 


_ _ ' J 
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Procedure  names  are  composed  of  alphameric  characters  and  must  begin 
with  a letter.  The  names  must  not  conflict  with  any  of  the  standard 
mathematical  functions  available  in  CSL,  the  keywords  COMPLEX,  RADIANS, 
or  DEGREES,  or  any  of  the  special  functions  and  modifiers  available  in 
CSL,  namely,  SENS,  PT,  PV,  IV,  D,  S,  Q,  E,  F,  N,  A,  B,  Y,  Z,  I,  V,  U, 
and  P. 

The  formal  parameter  names  are  composed  of  alphameric  characters  and 
must  begin  with  a letter.  The  names  must  not  conflict  with  any  other 
defined  name  which  can  be  referenced  in  a mathematical  expression. 

An  example  of  a procedure  definition  is: 

PROCEDURE,  MAXF(A,B,C) 

IF(A.GT.B)  G<2  T0  200 
MAXF=C(A-B)/N(1) 

RETURN 

200  MAXF=C(A+B)*N(1) 

RETURN 

END 

The  procedure  is  written  in  terms  of  network  quantities  and  other 
variables.  Note  that  all  values  must  be  passed  through  the  formal 
parameters  unless  the  value  is  known  from  the  level  of  network  description 
on  which  the  procedure  appears.  Character  string  replacement  may  be 
accomplished  through  the  formal  parameters. 

A procedure  may  be  referenced  by  simply  including  it  as  part  of  a 
mathematical  expression,  substituting  the  desired  quantities  and  character 
strings  for  the  formal  parameters.  For  example: 

G=MAXF  ( N ( 3 ) , N ( i* ) , TABLE 3 ) /MAXF  ( N ( 5 ) , N ( 6 ) , TABLE? ) 

During  computation  the  first  call  to  MAXF  uses  N(3)  and  N(U)  as  the 
values  for  A eind  B,  and  replaces  the  symbol  C in  the  procedure  definition 
with  TABLE3;  similarly  the  second  call  to  MAXF  uses  N(5)  and  N(6)  values 
Eind  replaces  C with  TABLE?.  The  quantity  N(l)  must  be  defined  on  the 
nesting  level  at  which  the  procedure  appears. 
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i.  Tables 


'The  language  has  facilities  for  describing  both  one  and  two 
dimensional  tables.  Linear  interpolation  between  listed  values  is  used. 
Out  of  bounds  values  will  be  determined  by  extrapolating  the  slope  of  the 
table  function  at  the  appropriate  boundary.  Only  numbers  may  be  used  to 
express  the  numerical  values  in  the  table  definition. 

The  format  for  a one  dimensional  table  is: 

TABLEn 


m m 


where;  x^  = the  kth  coordinate  numerical  value  corresponding  to  the  table 
argument 

y = the  kth  numerical  value  of  the  table  corresponding  to  x 
K K 


Periodic  or  repetitive  tables  may  be  specified  by  inserting  the  letter  R 
for  the  value  of  y^.  This  indicates  that  the  table  is  to  be  repeated  indefi- 
nitely with  a period  - x^. 

A two-dimensional  table  describes  an  arbitrary  function  of  two  arguments. 
The  format  for  two-dimensional  table  definition  is: 

TABLEn,  2D 

y-, , y 


z 


• 

CVJ 

^m 

11’  ^12’  

^Im 

21’  ^22’  

^2m 

\l'  \2' 


km 
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where:  y^,  y2»  ••••  yjj^  are  the  numerical  values  of  the  second  argument 

used  to  define  the  table  values  z 

X , X , ....  X are  the  numerical  values  of  the  first  argument 
X.  d K 

used  to  define  the  table  values  z 


z^j  is  the  numerical  table  value  corresponding  to  the  specified 
values  of  x.  and  y. 

1 i 


Examples  of  one  and  two  dimensional  table  references  are: 

TABLE56(TIME) 

TABLE35F(CX,CZ) 

J . Time  Domain  Response  Variables 

The  following  forms  are  used  for  the  time  domain  response  variables 
where  Elnarae  is  the  element  name  and  Node  is  the  node  name  involved. 

N(Node)  for  nodal  voltage  response 

l(Elname)  for  element  current 

V(Elname)  for  element  voltage 

P(Elname)  for  element  power 

E(Elname)  for  element  stored  energy 

F(Elname)  for  magnetic  flux  in  element 
Q(Elname)  for  electric  charge  in  element 

k.  Frequency  Domain  Response  Variables 

In  the  frequency  domain  the  network  solution  is  generally  complex; 
thus  one  must  be  able  to  differentiate  between  the  real  and  imaginary  com- 
ponents of  the  response.  This  is  done  by  appending  a character  denoted  by  x 
after  the  response  designation  character.  The  letter  x may  represent  the 
following  characters : 

X = M for  magnitude 

D for  phase  angle  in  degrees 

P for  phase  angle  in  radians 

R for  real  component 

I for  imaginary  component 
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The  response  variables  for  the  frequency  domain  are : 


Nx(Node)  for  nodal  voltage  response 
Ix(Elname)  for  element  current 
Vx(Elnarae)  for  element  voltage 
Px(Elname)  for  element  power 


The  network  must  include  at  least  one  complex  source  in  order  to 
produce  a nonzero  network  response  for  the  above  response  variables. 


The  two  port  small  signal  transfer  functions  are  also  available  in 
the  language.  These  assume  either  open  circuit  current  or  short  circuit 
voltage  excitation  with  a unit  amplitude  sinusoid  of  zero  phase  on  the 
input  port,  and  specify  either  the  open  circuit  voltage  response  or  the 
short  circuit  current  flow  across  the  output  port.  Thus,  one  can  determine 
voltage  gain,  current  gain,  transfer  and  driving  point  admittance,  and 
transfer  and  driving  point  impedance  by  a suitable  set  of  port  terminal 
conditions.  The  transfer  functions  are  denoted  by: 


Ax(a-b/c-d ) 
Bx(a-b/c-d ) 
Yx(a-b/c-d ) 
Zx(a-b/c-d ) 


for  voltage  gain 
for  current  gain 
for  transfer  admittance 
for  transfer  impedance 


where  the  output  port  is  designated  by  node  a with  respect  to  node  b,  the 
input  port  is  designated  by  node  c with  respect  to  node  d,  and  x has  the 
same  meaning  as  before. 

Abbreviated  versions  of  this  notation  are  available.  If  either  node  b 
or  node  d is  the  datum  node  it  may  be  left  out.  If  nodes  c and  d are 
identical  to  node  a and  b,  respectively,  the  c and  d nodes  may  be  left 
out.  Equivalent  examples  are: 

ZM(2-0/2-0) 

ZM(2-0/2) 

ZM(2/2) 

ZM(2) 

ZM(2-0) 
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l.  Network  Sensitivity  Matrix 

The  network  sensitivity  matrix  may  be  calculated  in  the  large 
signal  DC  and  transient  solution  and  in  the  frequency  domain  solution. 

The  network  sensitivity  matrix  consists  of  the  partial  derivatives  of  a 
vector  of  network  response  variables  with  respect  to  a vector  of  network 
parameters.  An  example  of  the  notation  for  the  network  sensitivity  matrix 
is : 

SENS(N(5),  I(L5),  DISPLACEMENT/F0RCE , R66) 

where  N(5),  l(L5),  and  DISPLACEMENT  are  the  response  variables  and  F0RCE  and 
R66  are  network  parameters.  This  example  produces  a 3x2  matrix  of  sensi- 
tivities . 

m.  Value  Modifiers 

Any  element  parameter,  global  variable  (except  FREQ),  real  variable, 
or  time  domain  response  variable  may  have  a modifier  prefixed  to  it  to 
designate  related  time  or  iterative  values.  Letting  Name  denote  the 
symbolic  name  of  the  quantity  for  which  a related  value  is  desired,  we 
have  the  following  forms  available : 

Name  for  current  value 

PT(Name)  for  value  at  previous  time  step 

PV(Name)  for  value  at  previous  iteration 
IV(Name)  for  initial  value  (at  time  = O) 

D(Name)  for  time  derivative  value 

S(Name)  for  time  integral  value 

1* . SOLUTION  CONTROL 

The  network  description  language  which  has  been  presented  only  describes 
the  network  configuration  of  interest.  It  does  not  provide  for  any  calcula- 
tion of  network  response.  Response  calculation  is  initiated  by  specifying 
one  or  more  solution  entries.  The  solution  entries  are  executed  in  the 
order  in  which  they  are  encountered  in  the  input  deck.  The  solutions 
available  are  nominal  response,  Monte  Carlo,  optimization,  and  worst  case. 
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A solution  entry  may  require  additional  information  to  enable  proper 
execution.  This  information  may  be  specified  by  run  controls,  initial 
conditions,  network  parameter  value  changes,  swept  and  parametric  variables, 
the  B0UNDS  entry,  and  the  CURVE  entry.  These  topics  are  discussed  before 
the  solution  entries  are  presented. 

In  the  discussion  which  follows  the  term  normal  value  is  used.  The 
normal  value  is  the  value  of  a quantity  which  is  used  when  no  change  in 
value  is  specified  by  the  user  in  a particular  solution. 

a.  Run  Controls 

CSL  permits  the  user  to  specify  run  controls  globally,  within 
nominal  solutions,  Monte  Carlo  solutions,  optimization  solutions,  and  worst 
case  solutions,  and  within  state  entries  of  optimization  solutions.  Specific 
run  controls  are  not  included  in  this  discussion  since  the  CSL  language  has 
the  capability  of  handling  an  unlimited  set  of  run  controls.  Thus,  the 
choice  of  a particular  set  of  run  controls  depends  upon  a particular  imple- 
mentation of  CSL  and  not  the  CSL  language  in  general. 

The  grammar  of  the  CSL  language  permits  six  basic  forms  of  run 
controls.  The  basic  forms  are: 

Keyword 

Keyword  = Keyword 
Keyword  = Integer 
Keyword  = Real  number 
Keyword  = Math  expression 
Keyword (Boolean  expression) 

The  Boolean  expression  may  be  of  any  complexity  using  FORTRAN  rules 
for  combining  Boolean  operators,  arithmetic  relational  operators,  and 
mathematical  expressions. 

b.  Initial  Conditions  Specification 

The  user  may  specify  the  initial  conditions  to  be  assigned  to  any 
network  variable  for  which  initial  conditions  has  meaning.  This  is  done 
by  means  of  the  INITIAL  C0NDITI0NS  entry  which  may  be  specified  either 
globally  or  locally  within  a solution  entry. 
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The  first  card  of  the  entry  contains  the  words  INITIAL  CONDITIONS; 
the  last  card  is  an  END  card.  The  intervening  cards  specify  the  network 
variable  name  (using  main  network  description  notation)  and  the  value  of 
the  initial  condition.  For  example: 

INITIAL  C0NDITI0NS 
V(C3)  = .075 
I(L3)  = 1200.5 
VEL  = 2.9 
END 

c.  Network  Parameter  Value  Changes 

Network  parameter  values  may  be  changed  to  a different  value  during 
a particular  solution  by  specifying  the  parameter  name  and  the  new  value. 
The  parameter  name  corresponding  to  the  main  network  description  notation 
is  used.  The  new  value  may  be  given  as  either  an  actual  value  or  as  a 
relative  value.  A relative  value  is  denoted  by  a number  suffixed  with  an 
asterisk;  the  actual  value  is  then  the  product  of  the  normal  value  and  the 
specified  number. 

Examples  are : 

R12  = 350/C3 
C23  = .85* 

D2.TH  = 1.89*I(D2) 

GT6.FY7.T35. BN  = .55* 

FREQ  = 367 

d.  Swept  and  Parametric  Variables 

Quantities  may  be  stepped  through  a series  of  values  during  a 
solution  by  designating  them  as  swept  and  parametric  variables.  Only  one 
quantity  may  serve  as  a swept  variable.  There  may  be  as  many  pareimetric 
variables  as  desired.  The  parametric  variables  are  held  at  a particular 
value  while  the  swept  variable  is  swept  through  its  range.  Then  the 
parametric  variables  are  stepped  to  their  next  value  and  the  swept  variable 
is  again  swept  through  its  range.  In  this  way,  a family  of  curves  me^'’  be 
generated  through  the  use  of  these  two  types  of  variables. 
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An  example  of  a swept  variable  and  two  parametric  variables  is 
given  by: 

FREQ  = .005,  (25L0G),  1,5* 

*R12  = 1,  (3),  U,  10,  (2L5)G),  20,  35 
»R3l+  = 10,  (2),  15,  20,  50,  100,  (2),  200 

Parametric  variables  are  distinguished  from  swept  variables  by  prefixing 
them  with  an  asterisk.  Thus,  in  the  above  example,  the  swept  variable  is 
FREQ  and  the  parametric  variables  are  R12  and  R3^. 

Only  numbers  may  be  used  in  specifying  the  values  for  swept  and 
parametric  variables.  Note  that  some  numbers  are  enclosed  by  parentheses 
while  others  are  not.  The  numbers  which  are  not  enclosed  by  parentheses 
represent  specific  values  to  be  assumed  by  the  variable.  If  these  mambers 
are  suffixed  with  an  asterisk,  the  relative  value  is  indicated;  the  actual 
value  is  then  the  product  of  the  normal  value  and  the  relative  value. 

The  number  in  parentheses  indicates  a step  number,  which  is  the  number 
of  steps  involved  when  incrementing  from  the  preceding  value  to  the  succeeding 
value.  Normally,  linear  steps  are  used;  however,  if  the  word  I/^G  is  appended 
to  the  number  in  parentheses,  logarithmic  steps  are  used.  The  written  number 
sequence  may  not  begin  or  end  with  step  numbers , and  two  step  numbers  may  not 
occur  in  succession  in  tne  sequence. 

When  more  than  one  parametric  variable  is  used,  the  total  number  of 
values  which  will  be  assumed  for  each  must  be  the  same. 

Thus,  in  the  example  shown  above,  R12  assumes  the  values  of  1,  2,  3, 

U,  10,  lU.lU,  20,  and  35;  while  R3U  assumes  the  values  of  10,  12.5,  15, 

20,  50,  100,  150,  and  200. 

If  TIME  is  specified  as  either  a swept  or  parametric  variable,  the 
user  must  insure  that  the  sequence  of  time  values  which  he  specifies  is 
monotonically  increasing.  If  the  termination  run  control  has  been  specified, 
the  word  FINAL  may  be  used  to  specify  the  value  of  TIME  when  the  termination 
condition  is  first  satisfied: 

TIME  = 0,  (3),  600,  FINAL 
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e.  BOUNDS  Entry 


The  user  may  specify  the  upper  and  lower  limits  which  network 
parameters  may  assume  by  means  of  the  B(?UNDS  entry.  The  BCJUNDS  entry 
may  be  specified  either  globally  or  locally  within  a solution  entry. 

The  BOUNDS  entry  is  required  by  the  Monte  Carlo,  optimization,  and 
worst  case  solutions. 

The  first  card  of  the  BOUNDS  entry  is  the  word  B^)UNDS;  the  last  card 
is  an  END  card.  The  intervening  cards  specify  network  parameter  names 
(using  main  network  description  notation)  and  their  minimum  and  maximum 
value  limits.  Relative  value  designations  may  be  used;  in  such  a case 
the  actual  value  is  the  product  of  the  normal  value  and  the  relative  value. 

If  the  BOUNDS  entry  is  to  be  used  in  conjunction  with  a Monte  Carlo 
solution,  one  may  specify  distribution  shapes  for  individual  parameters. 

The  available  distribution  shapes  are  denoted  by  the  words  GAUSS,  RECT, 

TRI , and  CURVEn. 

The  GAUSS  shape  is  a Gaussian  curve  with  the  limit  values  specified  at 
the  3o  points. 

The  RECT  shape  is  a uniform  distribution  between  the  two  limit  values. 

The  TRI  shape  is  a triangular  distribution  wivh  the  limit  values 
corresponding  to  the  bottom  corners  of  the  triangle,  and  the  normal  value 
corresponding  to  the  apex  of  the  triangle.  Obviously,  the  normal  value 
must  fall  between  the  two  limit  values. 

The  CURVEn  shape  specifies  an  arbitrary  shape  corresponding  to  the 
named  CURVE  entry.  The  first  limit  value  corresponds  to  the  minimum 
value,  the  second  to  the  maximxim  value  in  the  appropriate  CURVE  entry. 

If  the  distribution  shape  is  not  specified  the  RECT  shape  will  be 
used  by  default.  The  distribution  shape  information  is  Ignored  for 
optimization  and  worst  case  solutions. 
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Normally,  the  distribution  shape  is  applied  in  linear  space.  The 
user  may  elect  to  apply  the  distribution  shape  in  logarithmic  space 
rather  than  linear  space;  this  is  done  by  including  the  word  L^G  following 
the  distribution  shape  specification. 

An  example  of  the  BOUNDS  entry  is : 

BOUNDS 

R2=12,15 

GT7.R1=0.5*  , 1.5, CURVES, I^G 
R6=PR0CEDURE  XYZ(12,J),.14»,RECT 
END 

f.  CURVE  Entry 

The  CURVE  entry  specifies  a weighted  curve  which  may  be  used  by 
the  optimization  and  Monte  Carlo  solutions.  The  format  is: 

CURVEn 


where:  x^,  x^,  etc.  = values  of  the  independent  variable. 

^1’  ^2’  ~ values  of  the  curve  corresponding  to  x^,  x^,  etc. 

Wi , Wg,  etc.  = values  of  the  curve  weights  corresponding  to  x^,  x^,  etc. 

The  specification  of  the  weights  for  any  point  is  optional.  If  the 
weight  is  not  specified,  it  is  assximed  w^  = 1. 

When  the  curve  is  utilized  by  the  Monte  Carlo  solution,  the  curve  weights 


are  ignored . 


g.  Nominal  Solution 

The  nominal  solution  consists  of  one  or  more  network  response 
calculations  corresponding  to  a prescribed  set  of  values  of  network 
parameters.  The  normal  network  parameter  values  are  used  in  the  calcu- 
lation except  where  specifically  superseded  in  a given  nominal  solution. 

Each  nominal  solution  is  specified  by  a RUN  entry  which  must  include 
an  output  specification.  The  first  card  of  the  entry  is: 

RUN 

This  card  is  followed  by  one  or  more  cards  which  specify  output, 
changes  in  the  values  of  network  parameters , swept  and  parametric  variables , 
initial  conditions,  and  run  controls.  The  entry  is  terminated  by  an  END 
or  ENDRUN  card. 

The  main  network  description  notation  is  used  in  referring  to  the 
network  parameters . 

(l)  Output  Statements 

The  output  statements  specify  which  response  variables  are 
to  be  calculated,  and  how  the  results  are  to  be  presented.  Since  it  is 
possible  to  vary  network  parameters  over  a range  of  values,  the  output 
statements  can  include  plotting  specifications. 

Quantities  which  may  appear  as  output  include  all  network  parameters, 
global  variables,  real  variables,  response  variables,  and  mathematical 
expressions  involving  these  quantities. 

(a)  Print  Statement 

This  statement  specifies  the  quantities  which  are  to  be 
printed.  An  example  is: 

PRINT,  Rl,  HT5.T35.BN,  N(l),  AD(l-0/2-0),  N(2),  FREQ 

This  statement  causes  the  printing  of  the  quantities  which  are  named 


in  the  statement. 


Normally  the  printed  listing  uses  the  symbolic  names  of  the  requested 
quantities  for  labeling  purposes.  The  user  may  specify  a different  label 
for  a quantity  by  including  that  label,  enclosed  by  parentheses,  immediately 
following  the  symbolic  name.  For  example: 

PRINT,  N(  3)  ((OUTPUT),  r6(GAIN),  L3 

(b)  Plot  Statement 

This  statement  specifies  the  quantities  to  be  plotted 
as  well  as  the  coordinate  system  to  be  used  in  plotting.  The  independent 
variable  is  specified  last,  and  is  introduced  by  a / character.  If  no 
coordinate  system  is  specified,  a linear  system  is  used.  Each  plot 
statement  produces  a separate  graph.  Examples  of  plot  statements  are: 

PL0T,  N(L) 

PL0T,  LINL0G,  AM(l-0/2-0),  ZM(l-0/l-0),  /FREQ 

As  many  dependent  variables  as  desired  may  be  listed.  Obviously,  only 
one  independent  variable  may  be  named. 

Coordinate  systems  are  specified  after  the  word  PL0T.  Choices  are: 

No  specification  Linear  in  both  dependent  and  indepei'dent  variables. 

LINL0G  Linear  dependent  and  logarithmic  independent  variables. 

L^GLIN  Logarittimic  dependent  and  linear  independent  variables. 

L<iGL0G  Logarithmic  in  both  dependent  and  independent  variables. 

P0LAR  or  NYQUIST  Dependent  variable  is  plotted  on  polar  coordinates  (linear 
magnitude  and  phase)  as  a sequence  of  points  corresponding 
to  the  swept  variable  values. 

For  P0LAR  or  NYQUIST  plots  an  independent  variable  is  never  specified 
because  both  coordinates  refer  to  the  dependent  variable.  The  format  is 
shown  by  this  example: 

PL^T,  P<«LAR,  AM(3-0/2-U),  ZM(2-0/3-5) 

Obviously,  the  usage  of  PjiLAR  coordinates  is  restricted  to  the  frequency 
domain  response  variables.  The  magnitude  of  the  frequency  domain  response 
variable  is  always  specified  when  using  P^LAR  coordinates. 
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If  no  independent  variable  is  specified  for  a given  graph,  the  swept 
variable  will  be  used  automatically.  For  example: 

RUN 

R3=l,  (10),  20 
PL0T,  I(L3) 

will  produce  a plot  of  l(L3)  versus  R3. 

Normally  the  plotted  output  uses  the  symbolic  names  of  the  requested 
quantities  for  labeling  purposes.  The  user  may  specify  a different  label 
for  a quantity  by  including  that  label,  enclosed  by  parentheses,  immediately 
following  the  symbolic  name.  For  example: 

RUN 

PL0T,  N( 3) ((OUTPUT ) , R6,  /I (L3)( CURRENT) 
h.  Monte  Carlo  Solution 

The  Monte  Carlo  solution  synthetically  constructs  a large  number 
of  networks  using  parameter  values  chosen  from  specified  statistical 
distributions,  analyzes  the  performance  of  each  of  these  networks,  and 
then  summarizes  the  results  as  a set  of  performance  statistics. 

The  network  parameters  which  are  to  be  statistically  varied,  the 
statistical  distribution  shapes,  and  the  minimum  and  maximum  parameter 
values  to  be  associated  with  these  shapes  are  specified  in  the  B0UNDS 
entry  which  may  be  specified  globally  or  within  the  Monte  Carlo  entry. 

The  first  card  of  the  entry  is: 

RUN  M0NTE  CARL(? 

This  is  followed  by  output  specification  cards  and  optional  B0UNDS 
entry,  run  controls,  initial  conditions,  and  parameter  value  changes. 

The  entry  concludes  with  an  END  or  ENDRUN  card. 

Output  quantities  for  the  Monte  Carlo  Solution  may  include  all  net- 
work parameters , global  variables , real  variables , response  variables , 
emd  mathematical  expressions  involving  these  quantities. 
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Output  is  available  in  both  printed  listing  and  plotted  form.  If 
printing  is  specified,  the  tabulation  includes  each  individual  network 
calculation.  Plotted  information  is  presented  in  histogram  form. 

An  example  of  a Monte  Carlo  entry  is : 

RUN  M(?NTECARL(2 
RT=1.2* 

L5=L3/2 

PRINT,  Rl,  N(l) 

PL0T,  Tl.RBB 
PL0T,  AR(l-0/3-0) 

END 

i.  Optimization  Solution 

The  optimization  solution  attempts  to  attain  a desired  optimum 
by  a minimization  process  which  varies  specific  network  parameter  values 
within  an  allowable  parameter  space.  The  minimum  and  maximum  limits  for 
the  network  parameter  values  which  are  varied  to  produce  the  optimum 
condition  are  specified  by  the  B0UNDS  entry.  The  values  of  the  network 
parameters  which  produce  the  optimum  condition  automatically  replace  the 
normal  values  of  these  parameters  for  subsequent  solutions. 

The  optimization  solution  is  controlled  by  the  optimization  entry. 

The  first  card  of  this  entry  is: 

RUN  0PTIMI^TI0N 

This  is  followed  by  cards  which  specify  operational  state  information 
and  optional  B0UNDS  entry,  run  controls,  initial  conditions,  and  parameter 
value  changes.  The  entry  concludes  with  an  END  or  ENDRUN  card.  The  B0UNDS 
entry  must  not  be  introduced  as  a subentry  within  an  operational  state. 

Run  controls  and  parameter  value  changes  may  be  introduced  as  subentries 
within  the  optimization  entry  or  within  an  operational  state  entry. 

(l)  Operational  States 

The  operational  state  information  includes  changes  in  network 
pareuneter  values,  objective  function(s)  to  be  minimized,  run  controls, 
initial  conditions,  and  the  swept  variable  (if  any).  Parametric  variables 


are  not  permitted.  There  may  be  many  different  operational  states 
specified,  each  corresponding  to  a different  mode  of  operation  for  the 
network . 

Each  operational  state  is  introduced  by  the  card; 

STATE 

This  card  is  followed  by  one  or  more  cards  which  give  the  details 
for  that  particular  operational  state.  The  operational  state  is  terminated 
by  an  END  or  ENDSTATE  card. 

In  the  actual  optimization  process  all  of  the  operational  states  are 
considered  "simultaneously."  Thus  the  optimized  network  gives  the  "best" 
performance  in  each  of  the  states  specified. 

The  usage  of  the  operational  state  is  best  explained  by  referring  to 
an  extended  example : 

RUN  0PTIMIZATI0N 
C3=69 
STATE 

V6=-7 

S12=0 

TIME=0 

0BJ=N(1)/I(L5) 

END 

STATE 

;2BJ=I(L5)»»2,  CURVES,  .25 
S12=l 

0BJ=N(1),  CURVE5,  .50 
STATE 

0BJ  = AR(l-0/3-^),  CURVE2,  . 35 , X 
TIME=k7 

FREQ=10,  (2OL0G),  100 
END  RUN 

'Two  different  forms  of  objective  function  statements  are  permitted. 

One  form,  called  the  point  form,  is  used  when  only  a single  value  for 
each  network  response  variable  is  calculated;  the  other  form,  called  the 
curve  form,  is  used  in  conjunction  with  a swept  variaole. 
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The  point  form  is  shown  in  the  first  operational  state  in  the 
example  above.  It  consists  of  the  word  0BJ,  an  equal  sign,  and  a mathe- 
matical expression  whose  value  is  to  be  minimized.  This  mathematical 
expression  is  evaluated  only  once  during  a particular  response  calculation. 

If  the  DC  steady  state  response  is  specified,  then  it  is  evaluated  at  the 
DC  operating  point.  If  the  transient  response  is  specified,  it  is  evaluated 
at  the  termination  of  the  transient  calculation.  There  is  no  restriction  on 
the  form  of  the  mathematical  expression. 

The  curve  form  is  shown  in  the  second  and  third  operational  states  in 
the  above  example.  It  requires  a series  of  values  for  some  mathematical 
expression  for  various  values  of  a swept  variable.  If  the  swept  variable 
is  TIME,  a set  of  time  values  must  be  supplied. 

The  curve  form  is  specified,  in  order,  by  the  word  0BJ,  an  equal  sign, 
a mathematical  expression,  the  name  of  a curve,  a number  specifying  a 
weighting  constant,  and  an  optional  fitting  parameter. 

The  curve  form  actually  specifies  a curve  fitting  process.  The  curve 
name  refers  to  the  definition  of  a specific  curve  shape  which  is  included 
somewhere  else  in  the  input . It  is  required  to  fit  the  values  of  the 
mathematical  expression  as  closely  as  possible  to  the  curve  values  in  the 
least  squares  sense.  The  independent  variable  for  the  mathematical  expression 
values  and  the  curve  is  always  the  swept  variable. 

The  curve  is  normally  required  to  be  fit  as  exactly  as  possible  in 
the  least  squares  sense.  However,  by  including  the  operational  character  X 
at  the  end  of  the  curve  form  statement,  it  is  possible  to  do  the  fitting 
to  within  a linear  transformation.  This  transformation  will  be  chosen  by 
the  program  and  generally  its  value  is  of  no  interest  to  the  user. 

There  is  no  restriction  on  the  number  of  objective  functions  which 
may  appear  under  a given  operational  state.  Both  point  form  and  curve 
form  objective  functions  may  not  be  used  in  the  same  operational  state. 

The  optimization  solution  minimizes  the  sum  of  the  values  of  all 
objective  functions  for  all  specified  operational  states. 


j . Worst  Case  Solution 

The  worst  case  solution  is  specified  by  the  worst  case  entry. 

The  first  card  of  the  entry  is: 

RUN  W0RST  CASE 

This  io  followed  by  cards  which  specify  network  parameter  value 
changes,  initial  conditions,  and  output  requests.  The  END  card  terminates 
the  entry.  The  transient  response  calculation  cannot  be  calculated  in  the 
Worst  Case  Solution. 

The  B0UNDS  entry  must  be  included  either  globally  or  locally.  The 
output  quantities  for  which  the  worst  case  solution  is  desired  are  listed 
in  a PRINT  statement . The  worst  case  response  in  both  the  high  and  low 
directions  is  calculated  for  all  output  quantities  using  the  appropriate 
limit  values  for  the  parameters  specified  in  the  BOUNDS  entry.  Plotting 
of  worst  case  output  is  not  available. 
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SECTION  TV 


INITIAL  CSL  TOANSLATOR  DESIGN 

1.  PHILOSOPHY  OF  THE  CSL  TRANS uATOR 

The  CSL  Translator  performs  the  automatic  translation  of  source 
text  in  the  CSL  language  to  its  equivalent  in  the  NET-2,  SCEPTRE,  and 
CIRCUS-2  target  languages.  It  is  desirable  that  the  translator  be 
more  than  Just  a hard  coded  translator  between  these  languages.  For 
instance,  the  form  of  CSL  may  change  as  new  features  are  added  or 
existing  features  are  modified.  Translation  between  other  languages 
may  be  desired  at  a later  date.  These  considerations  dictate  the 
primary  design  philosophy  of  the  CSL  translator;  it  will  be  modular  and 
table  driven  to  the  greatest  extent  possible.  Furthermore,  the  tables 
which  control  the  translator  will  be  capable  of  formal  description, 
using  a higher  level  language  specifically  designed  for  such  description. 
In  this  way,  as  much  of  the  essential  description  of  the  translator  as 
possible  can  be  described  using  formal  techniques,  permitting  flexibility 
in  the  modification  of  the  translator  required  by  lexical,  grammatical, 
or  semantic  changes  in  any  of  the  languages  handled  by  the  translator. 

It  is  well  known  that  a language  can  be  described  by  three  kinds  of 
components;  lexical,  grammatical,  and  semantic.  Lexical  components 
comprise  the  "words"  of  the  language,  the  vocabulary  which  is  available 
for  constructing  sentences  or  text  streams  in  the  language.  These 
lexical  components  may  be  combined  through  a set  of  rules,  known  as  the 
grammar  of  the  language  (also  called  the  language  syntax),  to  produce 
properly  constructed  sentences  in  the  language.  Finally,  the  language 
semantics  give  meaning  to  the  sentence  which  has  been  constructed  so 
that  specific  information  is  conveyed  by  the  sentence. 
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ihe  language  translation  problem  is  concerned  with  all  three  aspects 
of  the  language.  Although  the  semantic  aspect  is  of  primary  concern 
during  actual  translation,  it  is  also  necessary  to  include  both  the 
lexical  and  grammatical  aspects  since  they  provide  a means  for  repre- 
senting the  source  and  target  texts.  The  formal  recognition  of  these 
three  aspects  of  a language  was  given  considerable  attention  during  the 
CSL  Translator  development  effort.  They  have  been  treated  in  modular 
fashion,  both  in  the  actual  software  design  and  in  this  report,  permitting 
changes  in  one  component  without  adversely  affecting  the  others. 

A number  of  formidable  problems  have  appeared  during;  the  translator 
design  and  development,  preventing  the  realization  to  date  of  a completed 
translator.  Many  of  these  problems  were  successfully  solved,  while  others 
still  remain.  This  report  doc\iments  various  aspects  of  the  project.  The 
remainder  of  this  section  discusses  initial  efforts  at  producing  a trans- 
lator. These  efforts  were  subsequently  abandoned  and  a more  comprehensive 
approach  was  pursued,  as  described  in  subsequent  sections  of  this  report. 

2.  INITIAL  CSL  TRANSLATOR 

During  the  early  stages  of  the  translator  project,  software  was 
developed  which  has  the  capability  of  translating  a subset  of  CSL  to  a 
subset  of  NET-2.  As  attempts  were  made  to  extend  the  concepts  which 
had  been  developed  to  larger  subsets  of  these  languages,  and  ultimately 
to  SCEPTRE  and  CIRCUS-2,  the  deficiencies  of  the  approach  which  had  been 
selected  became  sufficiently  important  that  it  was  not  feasible  to  continue 
translator  development  along  those  lines. 

The  CSL  translator  operates  from  a Backus-Naur  Form  (BNF)  of  both 
the  source  and  target  languages.  The  BNF  description  of  a language 
specifies  the  grammar  of  the  language.  If  the  BNF  description  is  carried 
to  the  character  level,  then  the  lexical  description  of  the  language  may 
also  be  specified  by  the  BNF.  This  approach  was  used  in  the  initial 
translator  design. 
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Specifically,  a method  of  expressing  the  grammar  and  lexical  aspects 
of  the  languages  was  developed,  using  a modified  BNP’  notation  which  was 
amenable  to  being  keypunched  (this  notation  was  somewhat  more  difficult 
to  read  than  the  notation  which  was  later  adopted  and  used  in  this  report). 

A special  program  was  written  which  transformed  the  BNP’  notation  into  a set 
of  tables  which  was  then  used  to  direct  the  parsing  of  the  text  stream  of 
the  language  of  interest . 

As  the  input  stream  was  parsed,  information  was  assembled  into  a 
canonic  data  structure  (CDS).  The  CDS  was  stored  as  an  n-ary  tree  structure 
in  which  sibling  nodes  represented  alternative  terms  in  the  BNF  productions, 
and  descendant  nodes  represented  nonterminal  expansions  in  the  BNF.  The 
actual  character  strings  which  formed  the  input  text  appeared  at  the  leaf 
level  of  the  tree. 

Each  nonterminal  in  the  BNF  was  assigned  a numeric  code  which  was 
stored  in  the  tree  structure.  Thus,  by  traversing  the  tree,  one  could 
readily  reconstruct  the  input  text,  as  well  as  inspect  the  parse  tree 
which  resulted  from  parsing  the  text. 

The  CDS  which  resulted  was  generally  too  detailed  and  required  more 
memory  resources  than  needed  for  the  essential  information  stored  in  it. 
Thus,  the  concept  of  tree  pruning  was  devised.  A special  marker  was 
embedded  in  the  BNF  as  a prefix  for  certain  terminal  and  nonterminal 
terms.  The  marked  terms  were  designated  as  essential  nodes  in  the  CDS. 

After  a subtree  of  the  CDS  had  been  formed,  it  was  pruned  by  eliminating 
any  serial  nodes  which  did  not  correspond  to  marked  terms,  providing  that 
the  removal  of  such  nodes  did  not  destroy  the  basic  structure  of  the  CDS. 
Thus,  the  CDS  was  compacted  by  removing  nonessential  nodes,  yet  the 
hierarchical  relationships,  as  expressed  by  the  underlying  BNF,  were 
preserved. 

The  first  phase  of  the  translation  process  was  now  complete,  that  is, 
the  source  text  stream  had  been  parsed  and  a canonic  data  structure 
generated. 


The  next  step  involved  trans formations  on  the  CDS  in  accordance 
with  the  specific  translations  to  be  made.  This  involved  operations 
on  the  CDS  tree  which  added,  deleted,  moved,  and  modified  nodes,  subtrees, 
ani  character  strings  at  the  leaves.  The  details  depenu  specifically  upon 
the  languages  involved.  At  the  completion  of  this  step  a new  form  of  the 
CDS  existed,  corresponding  to  the  target  language.  In  fact,  the  resultant 
CDS  was  exactly  that  CDS  which  would  have  resulted  at  the  completion  of 
the  first  phase  if  the  target  language  had  instead  been  the  source  language. 

The  target  text  was  now  generated  from  the  target  CDS  by  simply  per- 
forming operations  which  were  the  inverse  of  parsing  the  target  language. 
Again,  a BIIF  table  for  the  target  language  grammar  was  used  which  included 
term  markers  indicating  essential  nodes  in  the  target  CDS.  The  CDS  tree 
was  traversed,  ani  as  a result  of  traversal,  a correspondence  was  established 
between  the  target  BNF  and  the  essential  nodes  of  the  target  CDS.  This 
resulted  in  a specific  traversal  of  the  BNF  which  in  turn  generated  the 
target  text  as  output. 

A translator  which  was  constructed  using  the  above  techniques  which 
had  the  capability  of  translating  the  Monte  Carlo  entries  of  CSL  into 
the  corresponding  entries  in  NET-2.  Later,  the  translation  was  extended 
to  include  the  CSL  hun  entry  and  Optimization  entry,  with  translation  into 
the  NET-2  equivalents. 

As  this  approach  to  the  translator  design  continued  several  problems 
became  apparent.  First  of  all,  the  parsing  operation  was  of  the  top-down 
type  in  which  the  parse  tree  is  constructed  by  starting  with  the  grammar 
goal  symbol  and  attempting  to  build  the  tree  down  to  the  lexical  symbol 
level  (in  this  case,  the  character  level).  Thus  the  parser  exhibited  all 
of  the  problems  of  top-down  parsers.  Error  detection  was  delayed  until 
all  possible  parse  tree  constructions  had  been  investigated,  the  parser 
was  slow  in  operation  (particularly  in  this  case  since  parsing  was  carried 
down  to  the  character  level),  and  error  recovery  was  extremely  difficult. 
Certain  BNF  representations  were  found  to  trap  the  parser  into  dead  end 
situations  from  which  it  could  only  report  syntax  error,  when,  in  fact, 
there  was  no  syntax -error . 
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Problems  were  also  evident  in  resolving  keyvords  which  could  have 
several  different  semantic  interpretations  as  well  as  represent  identifiers, 
depending  upon  the  context  in  which  they  are  used.  The  magnitude  of  this 
problem  can  be  seen  by  the  complexity  of  the  lexical  analyzer  which  has  been 
successfully  developed  for  the  CSL  language,  as  shown  in  Appendix  F.  The 
initial  approach  to  CSL  parsing  could  not  adequately  handle  the  lexical 
analysis  requirements  demanded  by  the  CSL  language. 

The  CDS  depended  upon  the  particular  BNF  specification  of  the  gra.imar 
for  its  topological  structure.  Thus,  two  equivalent  BNF  representations 
of  the  same  grammar  could  generate  substantially  different  canonic  data 
structures  from  a topological  point  of  view  (the  same  information  was 
available  in  both,  but  linked  differently).  Since  the  transformation 
routines  required  knowledge  of  the  precise  topological  structure  of  the 
CDS,  it  can  be  seen  that  the  BNF  and  the  coding  of  the  transformation 
routines  were  completely  interdependent,  precluding  the  goal  of  modular 
independence  between  these  two  parts  of  the  translator.  The  problem  was 
further  compounded  by  the  fact  that  this  effect  occurred  on  both  the 
source  and  target  sides  of  the  translator. 

Finally,  the  CDS  transformation  routines  contained  considerable 
overhead  associated  with  the  initial  and  final  CDS  formats;  this  overhead 
had  no  relation  to  the  actual  semantic  translation  which  was  to  be  accom- 
plished. The  transformation  software  tended  to  become  very  unwieldy 
because  of  this. 

The  extension  of  the  initial  approach  to  include  larger  subsets  of 
the  languages  under  consideration  became  unfeasible.  A number  of  crucial 
problem  areas  had  been  illuminated  and  it  was  necessary  to  find  solutions 
for  them  before  continuing.  Accordingly,  this  approach  was  abandoned  and 
a new  approach  was  developed.  The  new  approach  solved  all  of  the  problems 
encountered  under  the  original  approach  and  had  far  greater  generality. 
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The  new  approach  uses  a flexible:  bottom-up  parser  coupled  with  a 
lexical  analyzer  to  solve  the  problems  associated  with  parsing,  error 
detection,  error  recovery,  and  lexical  analysis.  The  ability  to  couple 
semantic  routines  arbitrarily  with  the  parsing  operation  permits  the 
source  canonic  data  structure  to  be  independent  of  the  BNF  representation 
of  the  source  grammar.  The  transformation  from  source  to  target  canonic 
representation  is  accomplished  by  a generalized  translation  model  through 
which  data  structures  are  manipulated  through  a BNF  type  description  with 
associated  semantic  processing.  The  final  translation  from  target  canonic 
data  structure  to  output  strings  in  the  target  language  is  accomplished  by 
syntax  directed  translations  which  can  generate  output  strings  in  parallel 
with  the  parsing  of  the  target  canonic  data  structure. 

When  the  new  concepts  had  crystallized  and  their  feasbility  had  been 
established,  work  on  the  original  approach  was  suspended.  Clearly  the 
first  requirement  was  the  development  of  an  LR(k)  parser  and  a lexical 
analyzer  to  work  with  the  parser.  The  manual  construction  of  an  LR(k) 
parser  for  a grammar  of  the  size  of  the  CSL  grammar  is  clearly  impractical. 
Therefore,  effort  was  expended  in  producing  an  LR(k)  Parser  Generator 
which  accepted  the  :-!NF  description  of  the  CSL  grammar  (or  any  other  grammar 
for  that  matter)  and  generated  the  tables  required  by  the  parser  for  that 
grammar.  Similar  problems  associated  with  the  manual  generation  of  the 
lexical  analyzer  tables  resulted  in  the  development  of  a Lexical  Analyzer 
Generator  which  produced  the  lexical  tables  for  the  CSL  language  (or  for 
any  other  language  of  interest ) . 

For  the  CSL  translator  itself  an  LP(k)  parser  and  a lexical  analyzer 
are  needed  along  with  the  tables  which  program  them  for  a particular 
grammar  and  language.  However,  the  LR(k)  Parser  Generator  and  the  Lexical 
Analyzer  Generator  also  required  a parser  and  lexical  analyzer;  thus  the 
entire  system  was  developed  in  a bootstrap  fashion,  using  a primitive 
parser  and  lexical  analyzer  with  manually  generated  tables  as  a starting 
point,  and  building  up  to  the  final  general  purpose  system. 
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Following:  the  construction  of  the  basic  Parser  Generator,  its 
capability  was  extended  to  permit  semantic  routine  linkages,  error 
recovery,  and  syntax  directed  translations  to  be  handled.  The  resulting 
programs  provide  for  a language  implementation  system  which  has  appli- 
cability far  beyond  the  CSL  translator. 
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SECTION  V 


A GENERAL  TRANSLATION  MODEL 

This  section  and  all  subsequent  sections  of  this  report  describe 
work  accomplished  in  the  realization  of  the  CSL  Translator  following 
abandonment  of  the  initial  translator  design  discussed  in  Section  IV, 

The  general  approach  to  translation  is  discussed  in  this  section. 

1,  THE  TRANSLATION  MODEL 

Translation  may  be  viewed  as  a process  of  transforming  a set  of  input 
data  into  a set  of  output  data,  according  to  some  specified  rules.  In  this 
report  we  are  concerned  with  the  translation  of  one  artificial  language  into 
another;  i.e.,  the  translation  of  a source  language  into  its  equivalent  target 
language  representation.  The  source  language  of  interest  is  the  Common  Simu- 
lation Leuiguage  (CSL);  the  target  languages  are  the  problem  description 
languages  for  the  NET-2,  SCEPTRE,  and  CIRCUS-2  progi-ams. 

Any  valid  expression  in  a language  is  called  a sentence  of  the  language. 
P’or  purposes  of  this  report  a sentence  in  any  of  the  languages  under  con- 
sideration is  the  complete  problem  description  in  that  language;  i.e.,  the 
entire  CSL  input  deck  or  the  entire  output  deck  of  the  translator  is  con- 
sidered as  a sentence  in  the  respective  language.  The  complete  set  of  all 
valid  sentences  in  the  language  is  the  language  itself. 

Sentences  are  composed  of  a sequence  (or  string)  of  symbols.  In  English 
the  symbols  are  the  words  and  punctuation  which  make  up  a sentence.  In  the 
eirtificial  languages  under  consideration  the  symbols  represent  node  names, 
element  names,  keywords,  delimiters,  etc.  The  set  of  all  symbols  which  may 
be  used  in  composing  a sentence  in  a language  is  called  the  vocabulary  of 
the  language.  The  symbols  are  called  the  lexical  components  of  the  language. 

Sentences  are  composed  by  combining  symbols  into  certain  sequences 
according  to  a set  of  specific  rules.  These  rules  are  called  the  grammar 
of  the  language.  The  syntax  of  a language  refers  to  the  grammatical 
structure  of  sentences  in  the  language. 
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Thus,  we  see  that  the  grammar  of  a language  is  the  syntactic  description 
of  that  language.  Language  is  not  useful  however  until  the  meaning  of  the 
sentence  in  the  language  can  be  described.  The  meaning  of  a sentence  is 
given  by  the  semantics  of  the  language.  The  grammar  contains  no  semantic 
information  in  itself.  Syntactic  analysis  of  a sentence  permits  one  to 
determine  if  that  sentence  is  a valid  sentence  in  a particular  language; 
it  does  not,  in  general,  permit  the  translation  of  the  sentence  into  an 
equivalent  sentence  in  another  language.  Thus,  it  is  seen  that  syntactic 
analysis  permits  recognition  of  a sentence  in  a given  language,  whereas 
semantic  analysis  is  required  to  translate  the  sentence  into  another  language. 

The  process  of  decomposing  a sentence  into  its  component  parts  (down  to 
the  symbol  level)  is  called  parsing.  This  operation  is  accomplished  by  a 
parsing  algorithm  (or  simply,  a parser)  which  uses  a formal  description  of 
the  grammar  of  the  language  as  a program  to  direct  the  parse. 

The  parser  operates  on  terminal  symbols  as  input  data,  lliese  symbols  , 
however,  are  not  the  lowest  level  of  information  in  which  the  sentence  is 
written.  Symbols  are  composed  of  characters  Just  as  words  in  English  are 
composed  of  letters.  Thus,  it  is  necessary  to  have  a means  of  generating 
symbols.  This  is  accomplished  by  a lexical  analyzer  which  accepts  input  at 
the  character  level  and  outputs  symbols  according  to  a prescribed  set  of 
rules.  The  rules  for  generating  symbols  generally  depend  upon  the  grammatical 
context  in  which  they  appear.  Thus,  the  parser  must  have  the  ability  to 
inform  the  lexical  analyzer  as  to  which  set  of  rules  are  to  be  used  in 
generating  the  next  symbol  required  by  the  parser.  The  lexical  analyzer 
then  uses  these  rules  to  generate  the  next  symbol. 

The  lexical  analyzer  is  composed  of  one  or  more  scanners , where  each 
unique  set  of  rules  for  forming  symbols  corresponds  to  a particular  scanner. 
Thus,  the  parser  designates  the  scanner  to  be  used  by  the  lexical  analyzer, 
and  the  selected  scanner  has  a particular  set  of  rules  associated  with  it 
which  are  used  in  forming  symbols  from  the  characters  which  are  input  to 
the  scanner. 
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The  scanners  in  the  lexical  analyzer  receive  characters  as  input  infor- 
mation. These  characters  are  supplied  from  a device  called  a character 
generator.  The  character  generator  is  responsible  for  traversing  a data 
structure  and  extracting  characters  to  pass  on  to  the  lexical  analyzer. 
Traditionally,  the  character  generator  extracts  its  characters  from  punched 
card  images.  However,  in  the  model  for  translation  which  is  being  presented 
the  characters  are  not  restricted  to  keypunch  characters,  nor  is  the  data 
structure  restricted  to  card  images.  In  fact,  the  character  generator  may 
be  called  upon  to  traverse  any  kind  of  data  structure  and  extract  characters 
which  are  totally  unrelated  to  the  keypunch  characters.  This  concept  is 
central  to  the  generalized  translation  model  which  is  used  in  the  CSL  trans- 
lator. 

We  have  noted  that  the  translation  process  requires  both  syntactic  and 
semantic  analysis.  The  semantic  analysis  is  coupled  with  the  parsing  operation 
and  invoked  at  specified  points  during  the  parse  by  the  parser.  The  semantic 
analysis  is  accomplished  through  a set  of  semantic  routines.  The  semantic 
routines  have  access  to  information  developed  during  the  parsing  process  and 
are  able  to  construct  data  structures  which  may  be  used  as  input  to  the 
character  generator  in  a later  phase  of  the  translation  process. 

This  leads  us  to  the  concept  of  translation  phases.  The  translation 
can  be  considered  to  operate  in  a finite  set  of  phases.  In  any  phase  a 
data  structure  exists  which  contains  a sentence  in  a particular  language; 
this  language  may  be  either  the  original  fSL  language  or  an  intermediate 
language.  Associated  with  this  language  is  a set  of  grammatical  rules  stored 
in  a parsing  table.  Thus,  the  execution  of  a particular  phase  consists  of 
specifying  a particular  input  data  structure  and  a parsing  table.  The  parser 
uses  the  parsing  table  to  direct  its  syntactic  analysis  of  the  sentence 
contained  in  the  data  structure.  In  so  doing,  the  parser  needs  symbols 
which  it  obtains  through  the  designation  of  a particular  scanner  in  the 
lexical  analyzer.  The  scanner  needs  characters  in  order  to  form  the  symbols; 
these  characters  are  obtained  from  a particular  character  generator  associated 
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with  the  scanner.  The  character  generator  traverses  the  designated  data 
structure  and  so  obtains  the  characters  which  make  up  the  sentence  in  the 
data  structure.  Finally,  as  the  parse  progresses,  the  parser  invokes 
specific  semantic  routines.  These  semantic  routines  then  construct  a sentence 
in  a new  language  in  an  output  data  structure.  This  completes  the  translation 
phase . 

Tlie  final  phase  results  in  the  construction  of  a sentence  in  the  target 
language  using  an  output  medium  to  contain  the  sentence.  This  completes 
the  translation  process.  ITie  above  technique  can  be  extended  to  translations 
of  any  complexity.  It  has  the  virtue  of  being  highly  modular.  The  process 
can  be  formally  defined  at  every  step  of  the  overall  translation.  Thus, 
documentation  of  the  translation  technique  is  easily  achieved. 

The  parser  and  the  scanners  are  driven  by  tables.  Thus,  the  parser  and 
the  lexical  analyzer  with  its  associated  scanners  can  be  standardized  soft- 
ware packages,  independent  of  the  application  for  which  they  are  used;  in 

fact,  the  lexical  analyzer  contains  only  a single  scanner  the  multiple 

scanners  are  implemented  simply  by  switching  tables  on  the  single  scanner 
that  actually  exists.  Similarly,  the  multiple  parsers  are  in  reality  only 
one  parser,  with  table  switching  employed  to  accomplish  the  multiple  parser 
concept . 

On  the  other  hand,  there  actually  are  multiple  semantic  routines  and 
character  generators  since  these  perform  unique  operations  which  are 
dependent  upon  specific  data  structures  and  semantics.  It  has  not  been 
found  practical  to  implement  a standardized  semantic  routine  and  character 
generator  using  tables  to  program  their  specific  behavior. 

A schematic  representation  of  the  translation  model  discussed  above 
is  shown  in  Figure  3. 

2.  GRAMMAR  SPECIFICATION 

From  the  foregoing  brief  description  of  the  translation  model  it  can 
be  seen  that  all  activity  during  a translation  phase  is  dependent  upon  the 
action  of  the  parser.  Thus  it  is  necessary  to  have  a formalism  for  specifying 
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Figure  3-  General  Translation  Model 


the  grammar  of  the  language  whose  sentences  are  to  be  parsed.  Through  this 
formalism  one  can  then  construct  the  parser  tables  and  thus  control  the 
actions  of  the  parser. 

The  grammar  G of  a language  can  be  expressed  as  a U-tuple  G = (N,T,P,S) 
where : 

N = a set  of  nonterminal  metalinguistic  symbols 

T = a set  of  terminal  symbols 

P = a set  of  productions  or  rules  defining  the  nonterminals  N 

S = the  grammar  goal  symbol 

The  set  N is  disjoint  from  the  set  T;  i.e.,  a symbol  cannot  be  used 
both  as  a terminal  and  nonterminal.  Each  nonterminal  symbol  is  defined  by 
one  or  more  productions.  A production  is  an  ordered  set  (U,  x)  where  U is 
a single  nonterminal  symbol  called  the  production  goal  symbol  and  x is  an 
arbitrary  string  of  nonterminal  and  terminal  symbols  which  define  U.  A 
particular  nonterminal  symbol  S is  known  as  the  grammar  goal  symbol;  all 
otner  nonterminal  symbols  are  derivable  from  the  grammar  goal  symbol. 

A notation  known  as  Backus  Naur  Form  (BNF),  also  called  Backus  Normal 
Form,  is  particularly  convenient  for  describing  productions  of  the  grammar. 
In  BNF  the  ordered  set  (U,  x)  is  written  as 

U = X 

where  the  definitions  of  U and  x are  as  above.  Any  language  whose  grammar 
can  be  expressed  by  productions  of  this  form  belongs  to  the  class  of  context 
free  languages,  and  its  grammar  is  known  as  a context  free  grammar.  All  of 
the  grammars  used  in  the  CSL  translator  are  context  free  grammars . 

In  order  to  express  productions  in  BNF  it  is  necessary  to  adopt  some 
notational  conventions.  We  will  use  alphameric  identifiers  to  represent 
both  nonterminal  and  terminal  symbols.  An  identifier  used  in  this  context 
consists  of  a letter  followed  by  zero  or  more  letters  or  digits;  the  length 
of  the  identifier  is  arbitrary.  Terminal  symbols  may  also  be  represented 
by  arbitrary  strings  of  characters  (including  blanks);  such  strings  will 
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be  enclosed  by  a pair  of  $ symbols;  e.g. , $+  IS  A PLUS  SIGN$  is  such  a 
terminal  symbol. 


Productions  may  be  written  recursively;  i.e.,  the  production  goal 
symbol  may  appear  in  the  string  on  the  right  side.  The  grammar  goal  symbol 
will  always  be  the  production  goal  symbol  of  the  first  production  listed  for 
any  grammar. 

3.  LR(k)  PARSING 

Parsing  may  be  accomplished  by  two  general  methods.  The  first  method, 
known  as  the  top-down  method,  starts  with  the  grammar  goal  symbol  and  proceeds 
to  traverse  the  tree  defined  by  the  grammar  down  to  the  terminal  symbols, 
looking  for  a match  with  the  symbols  of  the  sentence  being  parsed.  This 
method  is  a trial  and  error  process  involving  much  backtracking  and  thus 
is  very  time  consuming.  Furthermore,  detection  of  an  error  in  the  input 
sentence  is  virtually  impossible  until  the  traversal  of  the  grammar  tree 
has  been  completed;  specification  of  the  error  location  and  subsequent 
recovery  is  quite  difficult  for  large  grammars  such  as  those  used  by  the 
CSL  translator. 

A far  superior  technique  is  the  bottom-up  method  in  which  the  parse 
starts  with  the  terminal  symbols  of  the  input  sentence  and  builds  towards 
the  grammar  goal  symbol.  Many  techniques  have  been  devised  for  imple- 
menting a bottom-up  parse.  The  technique  used  in  the  CSL  Translator  is 
the  LR(k)  method,  which  is  capable  of  parsing  a large  subset  of  the  deter- 
ministic context  free  grammars,  such  as  the  grammars  used  by  the  CSL 
Translator,  The  LR(k)  method  parses  by  making  a single  pass  on  the  symbols 
of  the  input  sentence  from  left  to  right,  performing  a reduction  to  a non- 
terminal whenever  the  rightmost  leaves  of  the  parse  tree  form  a production. 

In  the  event  of  a-mbiguity  in  making  the  reduction  by  a particular  production, 
the  LR(k)  method  requires  lookahead  of  at  most  k symbols  to  resolve  the 
ambiguity . 

The  LR(k)  parsing  technique  lends  itself  to  the  use  of  parsing  tables 
to  direct  the  parse.  This  permits  a single  parser  to  be  used  with  many 


different  grammars  simply  by  changing  tables.  Furthermore,  it  is  feasible 
to  generate  these  parsing  tables  automatically  given  a description  of  the 
grammar  in  BNF  notation. 

The  LR(k)  parser  which  is  used  in  the  CSL  translator  belongs  to  the 
class  of  machines  known  as  deterministic  push  down  automata.  It  can  be 
thought  of  as  a finite  state  machine  coupled  with  a pushdown  stack.  The 
parser  enters  a sequence  of  states  during  the  course  of  the  parse,  starting 
from  an  initial  state.  The  parser  makes  a transition  from  its  current  state 
to  a new  state  (called  the  destination  state)  depending  upon  either  the  next 
symbol  read  or  the  information  on  the  top  of  the  stack.  Ultimately,  the 
parser  reaches  a final  state  (called  the  accepting  state)  and  the  parsing 
action  is  complete. 

In  particular,  there  are  three  kinds  of  states  which  the  parser  can 
enter.  They  are  known  as  read  states,  apply  states,  and  lookahead  states. 
Initially  the  parser  begins  by  entering  a specific  read  state  with  the 
stack  empty.  When  it  reaches  the  accepting  state  the  stack  will  again  be 
empty.  The  action  which  occurs  in  each  type  of  state  is  detailed  below. 

Wiien  the  parser  enters  a read  state  it  immediately  pushes  the  identity 
of  the  read  state  onto  the  stack.  It  then  reads  the  next  symbol  in  the 
input  sentence.  This  symbol  is  obtained  from  the  lexical  analyzer  in  the 
form  of  a numerical  code.  The  parser  compares  this  symbol  code  with  a 
prestored  list  of  valid  symbol  codes  which  can  occur  at  that  point  in  the 
parse.  Associated  with  each  of  the  codes  in  the  list  is  a corresponding 
destination  state.  If  a match  is  found  for  the  symbol  code,  the  parser 
makes  a transition  to  the  appropriate  destination  state;  if  no  match  is 
found,  an  error  exists  in  the  input  sentence,  the  parser  announces  this 
fact,  and  an  error  recovery  routine  is  executed. 

The  parser  enters  an  apply  state  whenever  a BNF  production  in  the 
grammar  has  been  completed.  That  is,  the  top  n items  on  the  stack  represent 
the  n symbols  which  appear  on  the  right  hand  side  of  a particular  production 
(the  items  on  the  stack  may  represent  both  nonterminal  and  terminal  symbols; 
the  nonterminal  symbols  arise  from  the  actions  of  previous  apply  states). 
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Of  course,  the  stack  actually  contains  read  state  identities  which,  iu  turn, 
represent  the  symbols  of  the  production.  The  parser  performs  the  reduction 
to  the  production  goal  symbol  for  the  particular  production  which  has 
been  completed.  Tiiis  involves  popping  n - 1 read  state  identities  off 
the  stack,  corresponding  to  replacing  the  n symbols  on  the  right  hand  side 
of  the  production  with  the  production  goal  symbol.  The  initial  read  state 
identity  is  not  popped  off  the  stack  but  is  used  instead  to  select  the 
destination  state  for  the  parser.  This  remaining  read  state  identity  is 
known  as  the  top  state  (because  it  is  now  on  the  top  of  the  stack  following 
the  popping  operation).  The  parser  compares  this  top  state  with  a prestored 
list  of  top  states  which  are  permissible  at  this  point  in  the  parse.  Associated 
with  each  top  state  in  the  list  is  a destination  state.  The  parser  finds  the 
match  and  gets  the  corresponding  destination  state.  In  actual  practice,  one 
of  the  permissible  destination  states  is  declared  a default  destination  state; 
if  a top  state  match  is  not  found,  then  the  default  destination  is  automatically 
used.  This  does  not  Jeopardize  the  error  detecting  ability  of  the  parser  in 
any  way,  since  the  parser  is  still  deterministic  and  errors  are  discovered 
only  by  read  states. 

It  is  possible  for  ambiguities  to  arise  at  certain  points  in  the  parsing 
process.  Such  ambiguities  require  lookahead  states  to  resolve  the  ambiguity. 

In  the  ambiguous  situation  the  parser  does  not  have  sufficient  information 
to  select  the  correct  destination  state.  One  of  the  possible  destination 
states  is  always  an  apply  state.  In  addition,  there  will  always  be  at  least 
one  other  possible  destination  state  which  will  be  a read  state.  A 
lookahead  state  is  entered  to  resolve  the  eimbiguity.  In  the  lookahead 
state  the  parser  requests  additional  symbols  from  the  lexical  analyzer,  and, 
on  the  basis  of  these  lookanead  symbols,  determines  the  proper  destination 
state.  Thus,  as  a result  of  the  lookahead  inspection  it  meiy  enter  a read 
state  or  some  apply  state.  In  an  LR(k)  parser  the  maximum  number  of  symbols 
which  must  be  supplied  in  order  to  resolve  all  ambigaous  situations  is  k 
symbols.  For  a particular  lookahead  state  not  all  k symbols  may  be  required 
(unless,  of  course,  k = 1). 
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The  symbols  which  are  delivered  by  the  lexical  analyzer  arc  not  read 
by  the  "Parser  in  the  lookahead  state,  but  only  inspected;  in  other  words, 
the  parser  will  request  these  same  symbols  again  when  entering  subsequent 
read  states.  However,  since  the  lexical  analyzer  delivers  a particular 
symbol  only  once,  the  lookahead  state  queues  these  lookahead  symbols  within 
the  parser  on  a first-in-first-out  basis.  Subsequent  read  states  then 
obtain  symbols  from  the  queue  instead  of  from  the  lexical  analyzer  until 
the  queue  is  emptied.  In  this  way  the  lexical  analyzer  is  not  required 
to  backtrack  its  operation,  just  as  the  narser  never  backtracks. 

The  LR(k)  parsing  algorithm  may  now  be  stated  (see  Appendix  0 for 
structured  programming  conventions  used  in  displaying  algorithms): 

*DESTINATION  STATE  = INITIAL  READ  STATE 

*D0  WHILE(DESTINATION  STATE  NOT  ACCEPTING  STATE) 

*IF (DESTINATION  STATE  = READ  STATE)THEN 
*PUSH  READ  STATE  IDENTITY  ONTO  STACK 
*READ  NEXT  SYMBOL 
•CHECK  FOR  SYMBOL  !4ATUi 
•IF (SYMBOL  MATCH  FOUND )THEN 

•DESTINATION  STATE  = STATE  ASSOCIATED  WITH  SYMBOL 
•ELSE 

•SYNTAX  ERROR  - PERFORM  ERROR  RECOVERY 

•ELSE 

•IF (DESTINATION  STATE  = APPLY  STATE )THEN 
•POP  READ  STATE  IDENTITIES  OFF  OF  STACK 
•CHECK  FOR  TOP  STATE  MATCH 
•IF (MATCH  FOUND )THEN 

•DESTINATION  STATE  = STATE  ASSOCIATED  WITH  TOP  STATE  MATCH 
•ELSE 

•DESTINATION  STATE  = DEFAULT  DESTINATION  STATE 

•ELSE 

•DO  SYMBOL  LOOKAHEAD,  CHOOSING  DESTINATION  STATE  ASSOCIATED  WITH 
MATCHING  LOOKAHEAD  SYMBOL  STRING.  IF  NO  MATCH  FOUND,  DESTINATION 
STATE  = LOOKAHEAD  DEFAULT  DESTINATION. 

•STOP 
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The  parser  is  completely  deterministic;  thus,  if  it  receives  a symbol 
from  the  lexical  analyzer  which  is  not  a valid  symbol  at  that  point  in  the 
parse,  the  parser  will  announce  an  error  and  an  error  recovery  process  will 
be  initiated.  The  error  recovery  process  attempts  to  resume  correct  parser 
action  with  a minimiim  of  loss  of  offending  input  text.  'ITius  an  LR(k)  parser 
always  detects  errors  as  soon  as  they  are  encountered  and  attempts  to  recover 
from  the  error  situation  as  quickly  as  possible  so  as  to  be  able  to  detect 
additional  errors. 

Errors  which  are  detected  by  the  parser  are  known  as  syntax  errors  and 
are  related  to  the  grammatical  structure  of  the  sentence  being  parsed.  In 
addition  to  syntax  errors  there  are  semantic  errors  which  are  detected  by 
the  semantic  routines.  The  parser  is  incapable  of  detecting  semantic  errors 
because  they  are  independent  of  and  at  a higher  level  than  the  grammar.  Note 
also  that  the  only  source  of  syntax  errors  will  be  in  the  source  language 
input  text.  Input  sentences  to  all  subsequent  phases  of  the  translation  are 
generated  by  the  first  and  subsequent  phase  semantic  routines  and  are. thus 
syntax  error  free.  They  may  contain  semantic  errors,  however. 

Appendix  A contains  a detailed  discussion  of  the  LR(k)  parsing  method, 
including  the  method  of  generating  the  read,  apply,  and  lookahead  states 
for  a grammar.  Appendix  B discusses  the  LR(k)  Parser  Generator,  a program 
which  automatically  generates  LR(k)  parsing  tables  from  a BNP  description 
of  a grammar. 

U.  LEXICAL  ANALYSIS 

Lexical  analysis  is  performed  by  the  lexical  analyzer  which  can  be 
conceptually  regarded  as  being  composed  of  a set  of  scanners.  Whenever 
the  parser  requires  an  input  symbol  it  calls  upon  the  lexical  analyzer 
to  provide  that  symbol.  In  particular,  the  parser  designates  a specific 
scanner  to  provide  the  symbol.  The  reason  for  this  is  that  generally  it 
is  not  possible  to  construct  a single  scanner  which  car.  pi-ovide  all  the 
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symbols  required  by  the  parser  during  the  entire  course  of  the  parse  because 
of  conflicts  in  the  rules  of  combining  characters  to  form  symbols.  ITius, 
at  any  given  point  in  the  parse  it  is  required  that  all  the  possible  symbols 
which  the  parser  might  legitimately  receive  be  capable  of  being  constructed 
by  a particular  scanner  which  the  parser  designates. 

As  mentioned  earlier,  there  is  really  only  a single  scanner  'resident 
in  the  lexical  analyzer.  The  multiple  scann« r concept  is  actually  imple- 
mented by  selecting  an  appropriate  scanner  table  by  which  the  behavior  of 
the  single  scanner  is  programmed.  Thus,  we  will  speak  of  the  scanner  in 
this  report  as  meaning  the  collection  of  scanners. 

The  scanner  operates  as  a finite  state  machine  with  one  character  of 
lookahead.  The  scanner  is  composed  of  eight  subscanners,  any  of  which  may 
be  used  to  generate  a symbol.  The  choice  of  subscanner  is  made  on  the 
basis  of  the  first  character  used  in  generating  the  symbol.  By  means  of 
a table  lookup,  indexed  by  the  numerical  code  representing  the  first 
character,  a choice  of  subscanner  is  made.  The  various  subscanners  have 
different  properties,  including  the  ability  to  transfer  control  to  another 
subscanner,  another  scanner,  or  an  external  routine. 

The  lexical  analyzer  always  returns  a lexical  code  which  identifies 
the  lexical  symbol  to  the  parser.  In  addition,  a semantic  value  may  be 
returned  for  use  by  the  semantic  processing  which  is  coupled  to  the  parsing 
action.  The  semantic  value  may  be  a pointer  to  the  character  string  which 
comprises  the  lexical  symbol,  the  value  of  a numerical  constant  specified 
by  the  string,  or  any  other  arbitrary  information. 

The  details  of  the  lexical  analyzer  and  a description  of  the  Lexical 
Analyzer  Generator  which  automatically  generates  lexical  analyzer  tables 
can  be  found  in  Appendix  D. 
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5.  SEMANTIC  ROUTINE  INTE^^FACE 

The  parser  is  only  capable  of  recognizing  grammatical  constructs  in 
the  language;  it  has  no  ability  to  understand  the  meaning  of  the  sentence 
being  parsed.  Thus,  it  is  not  capable  of  handling  any  part  of  the  trans- 
lation process  directly  and  normally  provides  no  output  other  than  syntax 
error  messages.  On  the  other  hand,  translation  and  semantics  depend  upon 
a knowledge  of  the  grammatical  structure  of  the  sentence.  TTierefore  it  is 
natural  to  use  the  parser  to  initiate  various  portions  of  the  translation 
process . 

This  initiation  is  done  by  associating  a semantic  action  with  the 
recognition  of  a particular  production  in  the  grammar  through  the  speci- 
fication of  a semantic  code.  This  semantic  code  is  written  as  part  of  the 
BNF  notation  describing  the  production  and  it  selects  a particular  action 
within  the  semantic  routine  which  may  be  called  by  the  parser.  The  notation 
for  semantic  code  specification  requires  insertion  of  the  semantic  code  in 
parentheses  immediately  following  the  specification  of  the  production  goal 
symbol , for  example : 

MTL’RM(!4  5)  = MTERM  AOP  MFACTOR 

If  no  semantic  routine  linkage  is  required  the  semantic  code  designation 
is  omitted. 

In  order  that  the  semantic  routine  has  the  necessary  semantic  infor- 
mation to  work  with,  the  parser  pushdown  stack  actually  contains  infonriation 
cells.  These  cells,  in  turn,  contain  parse,  lexical,  and  semantic  components. 

The  parse  component  contains  the  read  state  history  of  the  parse  and  is 
essential  for  the  correct  functioning  of  the  parser.  The  lexical  component 
contains  the  symbol  codes  which  have  been  delivered  by  the  lexical  analyzer 
for  each  read  state.  The  lexical  analyzer  also  delivers  semantic  information 
along  with  the  symbol  code;  this  semantic  information  is  contained  in  the 
semantic  component.  The  semantic  information  is  usually  either  a pointer  or 
a value.  For  example,  if  an  identifier  is  delivered,  the  semantic  information 
consists  of  a pointer  to  the  identifier  character  string;  if  a real  number  is 
delivered,  the  semantic  information  may  be  the  value  of  the  number  in  binary  form. 
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Thus,  it  can  be  seen  that  the  semantic  component  permits  access  by  the 
semantic  routine  to  all  of  the  information  known  about  the  symbol.  Further- 
more, the  cells  on  the  pushdown  stack  are  in  direct  correspondence  with  the 
terms  of  the  production  which  has  been  recognized,  with  the  cell  on  the 
top  of  the  stack  corresponding  to  the  rightmost  production  term,  etc.  The 
parser  is  concerned  only  with  the  parse  component  (its  interest  in  the  lexical 
information  occurs  only  at  the  time  it  receives  the  symbol  code  from  the 
lexical  analyzer).  The  semantic  routine  is  primarily  concerned  with  the 
information  in  the  semantic  component,  and  only  moderately  concerned  with  the 
lexical  component;  it  is  totally  unconcerned  with  the  parse  component  (in  fact, 
it  is  incapable  of  interpreting  the  parse  component  information). 

When  the  parser  enters  an  apply  state,  it  has  recognized  a production, 
represented  by  the  stack  contents.  If  a semantic  code  has  been  specified 
for  the  production  the  parser  immediately  calls  the  semantic  routine. 

Using  the  semantic  code  as  an  index,  the  semantic  routine  performs  whatever 
actions  are  needed.  It  may  even  alter  the  contents  of  the  lexical  and 
semantic  components;  but  under  no  circumstances  may  it  alter  the  parse  com- 
ponent or  the  stack  pointer.  Following  completion  of  the  semantic  action  the 
parser  pops  the  stack  by  changing  the  stack  pointer,  examines  the  parse 
component  of  the  cell  on  top  of  the  stack,  and  makes  a transition  to  the 
appropriate  destination  state. 

The  semantic  code  = 1 is  reserved  for  performing  an  initial  semantic 
routine  call.  This  call  always  occurs  Just  before  the  parsing  action 
begins.  It  permits  any  initial  semantic  actions  to  be  performed.  Also, 
since  any  production  may  call  the  semantic  routine,  the  grammar  goal  symbol 
production  provides  a means  of  calling  the  semantic  routine  after  all  parsing 
has  been  completed.  Thus,  complete  freedom  exists  in  coupling  the  parsing 
action  with  semantic  actions. 

Generally,  the  semantic  routines  are  concerned  with  generating  a 
data  structure  which  contains  the  input  sentence  for  the  next  phase  of 
the  translation  process.  The  semantic  routine  also  provides  for  semantic 
error  checking;  for  example,  detection  of  a reference  to  a network  element 
which  has  not  been  defined. 
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6.  SYtiTAX  DIRECTED  TRANSLATION 


In  addition  to  the  general  capabilities  provided  by  the  semantic 
routine,  another  mechanism  is  useful  for  translation  to  sentences  composed 
of  character  strings.  It  is  known  as  syntax  directed  translation.  It  has 
the  virtue  that  it  can  be  expressed  directly  in  BNE  notation,  eliminating 
the  need  for  any  special  routines  to  accomplish  the  required  action. 

In  syntax  directed  translation  (SDT)  each  production  is  represented 
by  the  ordered  set  (U,  x,  y)  where  U is  the  production  goal  symbol,  x is 
a string  of  terminal  and  nonterminal  symbols  representing  the  definition 
of  U,  and  y is  a string  of  terminal  and  nonterminal  symbols  representing 
the  translation  of  x.  Since  U is  equivalent  to  x,  U is  also  equivalent 
to  the  translation  y of  x.  In  BNF  notation  the  ordered  set  is  written  in 
the  form 

U = X,  y 

In  writing  the  string  y we  require  that  all  nonterminals  in  y must  also 
appear  in  x.  The  terminal  symbols  in  y may  be  arbitrary.  Furthermore,  we 
associate  a particular  occurrence  of  a nonterminal  in  y with  a particular 
occurrence  of  that  nonterminal  in  x.  If  the  nonterminals  appear  in  the  same 
order  in  x and  y,  this  association  is  obvious  since  it  is  one-to-one.  For 
example : 

MTERM  = WTERM  $»$  MFACTOR,  $»$  MT;  RM  MFACTOR 

Here  we  see  that  the  first  occurrence  of  MTERM  in  x corresponds  to  the  first 
(and  only)  occurrence  of  MTEPiM  in  y,  the  first  occurrence  of  MFACTOR  in  x 
corresponds  to  the  first  occurrence  of  MI’ACTOR  in  y , etc . Thus , the  SDT 
consists  of  a mapping  of  nonterminals  in  one  string  to  those  in  another 
string.  There  is  no  mapping  permitted  for  the  terminal  symbols. 

It  is  possible  to  specify  mappings  which  are  not  one-to-one  between 
X and  y.  This  is  done  by  assuming  an  implicit  sequential  numbering  for 
each  kind  of  nonterminal  in  x;  y is  then  written  with  each  nonterminal 
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suffixed  with  the  number  of  the  corresponding  x nonterminal  enclosed  in 
parentheses.  For  example: 

A=BFBGCBC,  H C(2)  B(3)  B(1)  H B(3) 

where  A,  B,  and  C are  nonterminals,  and  F,  G,  and  H are  terminals. 

Note  that  particular  nonterminals  may  be  reused  or  omitted  with  this  scheme. 
Thus,  the  first  occurrence  of  C in  y corresponds  to  the  second  occurrence 
of  C in  X,  the  first  occurrence  of  B in  y corresponds  to  the  third  occurrence 
of  B in  X,  etc.  The  terminals  F and  G in  x have  no  relation  to  the  terminal 
H in  y. 

The  syntax  directed  translation  can  be  generalized  to  permit  several 
syntax  directed  translations  to  proceed  in  parallel  with  the  parsing.  Further- 
more, each  SDT  is  permitted  to  access  information  belonging  to  another  SDT. 

In  multiple  SDT  each  production  is  represented  by  an  ordered  set 
(U,  X,  Tl,  T2,  ....,  Tn)  where  U is  the  production  goal  symbol,  x is  a 
string  of  terminal  and  nonterminal  symbols  representing  the  definition  of 
U,  and  Tl , T2,  ...,  Tn  are  translations  of  x.  The  ith  translation  is 
represented  by  the  ordered  pair  (i,  y^^ ) where  y is  a string  of  ’•''rrainal 
and  nonterminal  symbols. 

In  BIJF  notation  a multiple  SDT  is  written  in  the  form 
U = x,  l=y^,  2 = y^,  '^"^n 

In  writing  the  strings  y we  require  that  all  nonterminals  in  y must  appear 
in  X.  Again,  the  terminal  symbols  in  y may  be  arbitrary.  We  associate  a 
particular  occurrence  of  a nonterminal  in  y with  a particular  occurrence  of 
that  nonterminal  in  x;  in  addition,  we  associate  the  semantic  value  of  a 
particular  nonterminal  in  y with  a particular  semantic  value  of  the  non- 
terminal in  X. 

Note  that  each  nonterminal  in  x has  n semantic  values  associated  with 
it,  one  for  each  translation  involved  in  generating  that  nonterminal.  Thus, 
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the  string  y for  each  translation  T may  designate  both  the  particular  non- 
terminal occurrence  in  x and  the  particular  semantic  value  attached  to  that 
nontermina.1  for  purposes  of  constructing  a particular  translation.  When 
the  reduction  to  U is  made,  the  n translations  will  correspond  to  the  n 
semantic  values  to  be  attached  to  U,  and  thus  the  association  is  maintained. 

We  may  append  an  ordered  pair  (j,i)  to  each  nonterminal  in  the  translation 
strings  y,  where  j designates  the  nonterminal  occurrence  in  x and  i designates 
the  semantic  value  of  that  nonterminal  to  be  used  in  constructing  y.  If  the 
nonterminals  are  referenced  in  the  same  order  that  they  appear  in  x,  the  J 
index  may  be  omitted  by  writing  (,i);  if  the  ith  semantic  value  is  used  in 
the  ith  translation,  the  i index  may  be  omitted  by  writing  (j);  and,  finally, 
if  both  i and  J can  be  omitted  no  ordered  pair  is  required  for  designation. 

An  example  of  a multiple  SDT  is  seen  in  the  following  example,  where 
the  production  rule  represents  reduction  of  the  product  of  a math  expression 
term  and  factor  to  a term,  the  translation  T1  represents  the  Polish  prefix 
notation  corresponding  to  the  product,  and  translation  T2  represents  the 
Polish  prefix  notation  for  the  total  differential  of  the  product: 

MTERM  = MTERM  $«$  f-IFACTOR , 1 = $»$  MTERM  MFACTOR,  2 = $+**$  MTERM  (l,l) 
MFACT0R(1,2)  MI’ACTOR  (l  ,1 ) fWERM(l,2) 

The  most  general  form  of  SDT  is  obtained  by  also  coupling  a semantic 
routine  with  the  SDT.  This  is  notated  by  simply  appending  the  semantic 
routine  code  number  in  parentheses  to  the  production  goal  symbol  as  before. 

When  the  parser  enters  an  apply  state  characterized  by  a syntax  directed 
translation,  it  first  executes  any  semantic  routine  which  may  be  designated. 

It  then  does  the  mapping  of  the  specified  SDT.  Since  the  output  of  the  SDT 
is  a string,  that  string  is  constructed  in  another  area  of  core  and  repre- 
sented by  a pointer.  The  reduction  of  the  production  to  the  production  goal 
symbol  is  then  made,  popping  the  stack.  Following  the  reduction,  the  semantic 
component  of  the  cell  on  top  of  the  stack  contains  the  pointer  to  the  string 
translation. 

If  a production  does  not  require  syntax  directed  translation  it  is 
written  in  the  conventional  manner  without  the  y part. 
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SECTION  VI 


CSL  TRANSUTOR  STRUC'TURE 

The  CSL  Translator  consists  of  two  main  phases.  Phase  1 reads  CSL 
source  text,  performs  lexical  analysis  of  the  character  string,  and  passes 
the  lexical  symbols  to  the  LR(k)  parser.  The  parser  assembles  the  lexical 
symbols  into  productions  which  are  specified  by  the  BNF  description  of  the 
CSL  grammar.  The  parser  calls  specific  semantic  routines  at  particular 
points  in  the  parse;  these  semantic  routines  assemble  the  canonic  data 
structure  which  contains  all  of  the  essential  information  represented  by 
the  input  text.  The  canonic  data  structure  depends  only  on  the  semantic 
aspects  of  the  source  language.  It  thus  represents  the  essence  of  the 
problem  described  by  the  input  text  without  being  encumbered  by  the  syntactic 
properties  of  the  language  user!  to  express  that  text.  In  fact,  any  equivalent 
language  could  be  used  instead  of  CSL  to  generate  an  identical  canonic 
data  structure. 

The  above  actions  comprise  Phase  1 of  the  translator  operation.  These 
actions  are  independent  of  the  target  language,  and  the  CDS  is  identical  for 
all  of  the  target  languages  for  a given  input  text. 

Phase  2 involves  a set  of  translation  steps  involving  selected  portions 
of  the  CDS,  followed  by  a syntax  directed  translation  of  the  resultant  data 
structure  to  the  target  language  output  text.  The  intermediate  translations 
involve  steps  which  are  both  dependent  and  independent  of  the  particular 
target  language.  These  steps  will  be  discussed  later. 

The  CSL  Translator  is  constructed  as  an  overlayed  program,  containing 
four  overlays.  The  first  overlay  accomplishes  Phase  1 in  which  CSL  text  is 
transformed  into  the  CDS.  The  other  three  overlays  represent  the  three 
target  language  translators,  respectively,  with  a common  segment  used  for 
target-language-independent  translation  steps  and  common  routines. 


75 


The  Phase  1 software  must  have  the  capability  of  coping  with  lexical, 
syntactic,  and  semantic  errors.  Lexical  errors  may  occur  because  of  improp- 
erly formed  keywords,  identifiers,  or  illegal  characters.  Syntactic  errors 
may  occur  because  of  improper  sequences  of  lexical  symbols.  Both  of  these 
errors  are  automatically  handled  by  the  lexical  analyzer  and  tl>e  parser  using 
error  recovery  embedded  in  the  CSL  BNF  through  user  specification.  Semantic- 
errors  may  occur  in  Phase  1 due  to  meaningless  or  undefined  items  in  the 
problem  specification.  These  errors  will  be  detected  in  the  semantic 
routines  which  construct  the  CDS.  If  any  of  the  three  types  of  errors 
occurs  during  Phase  1 the  program  will  halt  at  the  conclusion  of  that 
phase.  Thus,  only  error  free  input  will  actually  be  translated. 

It  is  possible  for  semantic  errors  to  be  detected  in  Phase  2 also. 

Such  errors  are  of  two  types:  l)  additional  errors  caused  by  improper 

problem  statement  in  the  CSL  text  which  are  discovered  by  further  semantic 
processing  of  the  CDS,  and  2)  errors  caused  by  entries  in  the  CDS  which 
cannot  be  expressed  in  the  target  language.  An  example  of  the  latter  type 
of  error  would  be  the  specification  of  a transient  optimization  in  CSL  with 
an  attempted  translation  to  SCEPTRE;  SCEPTRE  cannot  handle  transient  opti- 
mization. It  is  not  possible  for  lexical  and  syntactic  errors  to  occur 
during  Phase  2. 

1.  f-iACRO  SUBSTITUTIONS 

The  CSL  language  contains  a macro  substitution  feature  by  which  blocks 
of  one  or  more  logical  cards  may  be  defined  and  incorporated  by  reference 
into  other  parts  of  the  text  str'ng.  The  definition  of  such  blocks  is 
accomplished  by  the  TEXT  directive,  with  reference  made  through  the  USE  TEXT 
directive. 

It  is  necessary  to  process  these  text  blocks  in  the  order  in  which  they 
are  referenced  so  that  the  syntactic  and  semantic  analysis  may  be  made  in 
the  context  of  their  appropriate  location  in  the  input  text  structure.  This 
permits  meaningful  diagnostics  to  be  generated,  clearly  impossible  if  the 
text  blocks  are  processed  out  of  context,  as  shown  by  this  example: 
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I TEXTl 

PLOT,  LINLOG,  N(5) 

END  TEXT 

RUN 

USE  TEXTl 
END 

RUN  MONTECARLO 

r6,  gauss,  .9 

USE  TEXT] 

END 

In  this  example  TEXTl  represents  legitimate  CSL  text  except  when  used  in  the 
context  of  the  RUN  MONTECARLO  entry  (the  ke.’/word  LINLOG  is  not  permitted). 

It  is  necessary  that  the  definition  of  a text  block  be  known  at  the 
point  where  that  block  is  referenced.  Therefore,  in  order  to  avoid  a 
separate  pass  over  the  input  text  to  locate  all  TEXT  entries,  it  is  necessary 
that  all  TEXT  entries  appear  in  the  input  stream  before  the  corresponding 
USE  TEXT  directive. 

Wien  a text  block  definition  is  encountered,  it  is  stored  without 
^ syntax  analysis  in  a special  table.  Wien  the  corresponding  text  reference 

is  encountered,  the  character  generator  is  switched  to  extract  characters 
out  of  the  text  definition  table  instead  of  the  normal  input  stream.  In 
this  way  the  text  is  expanded  in  context  to  the  parser  as  though  it  had 
been  in  its  proper  position  in  the  input  stream.  At  the  conclusion  of  the 
text  definition  the  character  generator  is  switched  back  to  the  input  text 
stream.  A text  block  may  be  referenced  in  this  way  as  many  times  as  desired. 

Since  text  definitions  may  reference  other  text  definitions  it  is  possible 
for  a set  of  nested  references  to  be  processed.  The  character  generator 
is  provided  with  a stack  to  aid  in  entering  and  leaving  the  various  levels 
of  the  nested  structure. 

2.  CANONIC  DATA  STRUCTURE 

The  CDS  is  built  during  the  parsing  of  the  CSL  text  stream  by  semantic 
routines  which  are  called  by  the  parser  at  key  points  in  the  parse.  The 
CDS  is  organized  as  an  n-ary  tree.  The  nodes  of  the  tree  consist  of  data 
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blocks  which  are  interconnected  by  pointers. 

The  root  of  the  CDS  tree  is  a node  representing  global  data.  This 
data  consists  of  pointers  to  text  definition  blocks,  model  definition 
blocks,  device  definition  blocks,  the  global  network  description  block, 
the  global  level  procedural  block,  and  the  solution  blocks.  This  Global 
Block  is  the  only  block  which  is  required  in  the  CDS. 

At  any  level  in  the  CSL  input  there  may  be  more  than  one  entry  of  the 
same  type.  These  multiple  entries  are  linked  together  in  the  CDS  through 
a pointer  which  occupies  the  first  word  of  the  CDS  data  block  for  that 
entry  type.  All  other  pointers  in  a CDS  block  access  blocks  which  are 
subsidiary  to  the  accessing  block,  that  is,  they  are  nested  within  that 
block.  Each  of  the  CDS  blocks  is  given  in  detail  below. 

The  Global  Block  has  the  structure; 

1 Ptr  to  Subnet  Definition  Block  chain  for  MODEL  entries 

2 Ptr  to  Device  Block  chain 

3 Ptr  to  Subnet  Definition  Block  chain  for  global  level  subnetwork 
definitions 

U Ptr  to  Procedural  Data  Block  chain  for  global  level 
5 Ptr  to  Solution  Block  chain 

The  Subnet  Definition  Block  occurs  for  each  subnetwork  or  model 
definition.  It  has  the  structure; 

1 Ptr  to  next  Subnet  Definition  Block  in  current  chain 

2 Ptr  to  Subnet  Header  Block 

3 Ptr  to  Datum  Node  Block  chain 

I4  Ptr  to  Real  Variable  Definition  Block  chain 

5 Ptr  to  Subnet  Reference  Block  chain 

6 Ptr  to  Subnet  Definition  Block  chain 

T Ptr  to  Function  Definition  Block  chain 

8 Ptr  to  Table  Definition  Block  chain 

9 Ptr  to  Element  Reference  Block  chain 

10  Ptr  to  Procedure  Definition  Block  chain 

11  Ptr  to  Initial  Conditions  Definition  Block  chain 

12  Ptr  to  Comment  Block 
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The  Device  Block  describes  DEVICE  entries  and  has  the  structure: 

1 Ptr  to  next  Device  Block  in  current  chain 

2 Device  name 

3 Model  name 

U Ptr  to  Value  Block  chain 

The  Procedural  Data  Block  contains  information  associated  with  the 
problem  solutions.  It  has  the  structure: 

1 Ptr  to  Bound  Block  chain 

2 Ptr  to  Run  Controls  Block  chain 

3 Ptr  to  Initial  Conditions  Block  chain 
h Ptr  to  Curve  Block  chain 

The  Solution  Block  contains  information  relating  to  the  types  of 
calculation  which  may  be  specified  in  CSL.  Solution  Blocks  are  chained  in 
the  order  in  which  the  solutions  are  specified.  The  structure  is: 

1 Ptr  to  next  Solution  Block  in  current  chain 

2 Solution  type 

3 Ptr  to  Comment  Block  chain 
Ptr  to  Parameter  Block  chain 

5 Ptr  to  Swept  Variable  Block  for  swept  variable 

6 Ptr  to  Swept  Variable  Block  chain  for  parametric  variables 
T Ptr  to  Out  Block  chain 

8 Ptr  to  Procedural  Data  Block  chain 

9 Ptr  to  Solution  Block  chain  (for  subsolutions  as  in  optimization 
calculation) 

The  Subnet  Header  Block  contains  interface  infonnation  for  both  sub- 
network definitions  and  model  definitions.  The  structure  is: 

1 Subnet  name 

2 No.  of  dummy  nodes  = n 

3 No.  of  formet!  parameters  = p 
Dummy  node  names  (n  entries) 

Formal  parameter  names  (p  entries) 

The  Datum  Node  Block  has  the  following  structure: 

1 Ptr  to  next  Datum  Node  Block  in  current  chain 

2 No.  of  nodes  specified  = n 
Datum  node  names  (n  entries) 
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The  Real  Variable  Definition  Block  specifies  the  real  variables.  The 
structure  is: 

1 Ptr  to  next  Real  Variable  Definition  Block  in  current  chain 

2 Real  variable  name 

3 Ptr  to  lexical  pair  list 

The  lexical  pair  list  contains  the  lexical  and  semantic  code  values  for 
the  lexical  symbols  which  comprise  the  right  hand  side  of  the  equation 
defining  the  real  variable. 

The  Subnet  Reference  Block  contains  information  for  references  to  both 
subnetworks  and  models.  It  has  the  structure: 

1 Ptr  to  next  Subnet  Reference  Block  in  current  chain 

2 Subnet  prefix 

3 Subnet  name 

Ho.  of  nodes  = n 
5 Ptr  to  Value  Block  chain 
Node  names  (n  entries) 

The  Function  Definition  Block  describes  all  user  specified  functions. 
It  has  the  structure : 

1 Ptr  to  the  next  Function  Definition  Block  in  current  chain 

2 Function  name 

3 No.  of  formal  parameters  = p 
h Ptr  to  lexical  pair  list 

Formal  parameter  names  (p  entries) 

The  Table  Definition  Block  has  the  structure: 

1 Ptr  to  next  Table  Definition  Block  in  current  chain 

2 Table  neirae 

3 No.  of  rows  in  table  = r 

■*  No.  of  columns  in  table  = c 

Column  values  (c  entries,  present  only  if  two-dimensional  table) 

Table  data  (ordering  same  as  input  sequence) 
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The  Element  Reference  Block  contains  information  for  all  standard  ele- 
ments which  are  referenced,  using  one  block  for  each  element.  The  structure 
is : 

1 Ptr  to  next  Element  Reference  Block  in  current  chain 

2 Element  type 

3 Element  name 

h No.  of  nodes  = n 
5 Ptr  to  Value  Block  chain 
Node  names  (n  entries) 

The  Procedure  Definition  Block  specifies  procedures.  It  has  the  structure 

1 Ptr  to  next  Procedure  Definition  Block  in  current  chain 

2 Procedure  name 

3 No.  of  formal  parameters  = p 
Formal  parameter  names  (p  entries) 

Procedure  text 

The  Initial  Conditions  Block  has  the  structure: 

1 Ptr  to  next  Initial  Conditions  Block  in  current  chain 

2 Variable  name 

3 Variable  modifier 

U Ptr  to  lexical  pair  list 

The  variable  modifier  specifies  the  type  of  initial  condition  associated 
with  the  variable,  e.g. , V(Cl),  Q(Cl),  or  E(Cl). 

The  Comment  Block  has  the  structure: 

1  Ptr  to  next  Comment  Block  in  c’orrent  chain 
Comment  text 

The  Value  Block  is  used  to  store  value  specifications.  It  has  the 
structure : 

1 Ptr  to  next  Valu'-  Block  in  current  chain 

2 Value  name  , 

3 Ptr  to  lexical  pair  list 
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The  Bound  Block  specifies  information  in  the  BOUNDS  entry.  It  has  the 
structure : 

1 Ptr  to  next  Bound  Block  in  current  chain 

2 Parameter  name 

3 Ptr  to  Value  Block  for  first  specified  value 
U Ptr  to  Value  Block  for  second  specified  value 

5 Shape  name 

6 LOG  and  re'^ative  vaxue  flags 

T!ie  Shape  name  specifies  the  statistical  distribution  which  is  used,  if 
any.  The  LOG  and  relative  value  flags  are  bit  coded  flags. 

The  Run  Controls  Block  specifies  one  run  control  for  each  block.  It 
has  the  structure: 

1 Ptr  to  next  Run  Controls  Block  in  current  chain 

2 Run  Control  name 

3 Ptr  to  lexical  pair  list  (optional) 

The  Curve  Block  specifies  CURVE  entry  information  and  has  the  structure: 

1 Ptr  to  next  Curve  Block  in  current  chain 

2 Curve  name 

3 No.  of  entries  per  row  in  curve  data  = n 
Curve  entry  data 

The  Parameter  Block  specifies  modifications  to  be  made  to  parameter 
values  and  has  the  structxire : 

1 Ptr  to  next  Parameter  Block  in  current  chain 

2 Parameter  name 

3 Ptr  to  lexical  pair  list 

The  Swept  Variable  Block  is  used  to  contain  information  for  both 
swept  and  parametric  variables  and  has  the  structure: 

1 Ptr  to  next  Swept  Variable  Block  in  current  chain 

2 Parameter  name 

3 Ptr  to  lexical  pair  list 
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The  Out  Block  contains  inforroation  about  solution  output  displays 
and  has  the  structure : 

1 Ptr  to  next  Out  Block  in  current  chain 

2 Output  type  and  flags 

3 Ptr  to  Output  Variable  Block  chain  for  dependent  variables 
k F^r  to  Output  Variable  Block  for  independent  variable 

5 Curve  name 

6 Weight 

The  Curve  name  and  Weight  are  used  in  connection  with  objective  function 
specification . 

The  Output  Variable  Block  specifies  the  individual  output  quantities 
which  may  appear  as  output.  The  structure  is: 

1 Ptr  to  next  Output  Variable  Block  in  current  chain 

2 Ptr  to  Comment  Block  for  label  text 

3 Ptr  to  lexical  pair  list 

3.  TRANSFORMATIONS  ON  THE  CANONIC  DATA  STRUCTURE 

The  CDS  is  generated  by  the  initial  semantic  processing  of  the  CSL 
input  text.  Inherent  in  the  CDS  structure  is  a hierarchical  nesting  of 
subnetworks,  functions,  procedures,  tables,  real  variables,  etc.  In 
addition,  there  are  micro  substitutions  permitted  whereby  character 
strings  may  be  substituted  through  formal  parameter  specification  in 
subnetworks  sind  procedures . 

The  nesting  capabilities  of  CSL  far  exceed  the  capabilities  of  any 
of  the  target  languages.  Also,  the  target  languages  do  not  have  the 
capability  of  handling  micro  substitution.  Therefore,  it  is  necessary  to 
denest  the  CSL  description  into  a single  level  description,  making  micro 
substitutions  as  the  denesting  occurs,  so  that  the  final  denested  version 
is  in  a form  which  can  be  expressed  using  any  of  the  target  languages. 

The  denesting  process  is  complicated  by  the  fact  that  the  nesting 
process  may  involve  three  kinds  of  replacements:  terminal  node  name  re- 

placements, formal  parameter  replacements,  and  character  string  replacements. 
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These  replacements  are  not  necessarily  simple  replacements  involving 
adjacent  levels  in  the  hierarchy,  but  may  involve  promotion  of  a name  or 
string  through  many  levels  before  the  replacement  is  finally  completed. 

The  situation  is  further  complicated  by  the  fact  that  CSL  employs  the 
concept  of  "most  local  definition"  in  satisfying  references.  The  "most 
local  definition"  concept  locates  definitions  of  referenced  items  by 
starting  at  the  local  level  in  the  hierarchy;  if  no  definition  is  found, 
then  the  next  ancestral  level  is  checked,  and  so  on,  back  to  the  global 
level,  if  necessary,  in  order  to  find  a definition.  This  process  may 
also  be  carried  to  descendant  levels  in  the  hierarchy  by  using  the  nest 
notation,  involving  subnetwork  names  separated  by  dots.  Thus,  in  CSL  it 
is  possible  to  reference  any  quantity  in  the  hierarchical  tree  which  is 
either  encountered  in  the  path  back  to  the  tree  root  or  which  is  a member 
of  the  subtree  belonging  to  the  point  in  the  hierarchical  tree  from  which 
the  reference  is  made. 

It  should  be  noted  that  the  denesting  and  micro  substitution  process 
cannot  be  accomplished  until  the  CDS  or  its  equivalent  has  been  established. 
That  is,  denesting  can  occur  only  when  all  of  the  hierarchical  dependencies 
have  been  established  through  some  internal  data  structure  through  which 
it  is  possible  to  traverse  the  hierarchical  tree. 

It  is  necessary  to  transform  the  CDS  in  the  general  case  to  an 
alternate  structure  in  order  to  be  able  to  acconi^lish  the  final  translation 
to  the  target  language.  These  transformations  may  be  outlined  briefly 
as  follows: 

1.  All  micro  subsitutions  must  be  made,  regardless  of  target  language. 

This  may  result  in  replication  of  some  of  the  hierarchical  entitles. 
Replication  requires  internal  renaming  so  that  references  can  be 
made  to  the  proper  replicated  entity. 

2.  Formal  parameters  for  subnetworks  must  be  eliminated  for  all  languages. 
Again,  replication  and  internal  renaming  may  occur. 
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3.  The  "most  local  definition"  problem  must  be  addressed.  This  requires 
that  all  definitions  be  available  on  the  level  at  which  they  are 
required  for  reference  by  the  target  language.  This  may  involve 
replication  of  definitions  and  some  renaming. 

J*.  Only  a single  level  of  nesting  may  be  permitted  for  SCEPTRE  and 

CIRCUS-2.  This  involves  expansion  of  the  nest  hierarchcy  to  eliminate 
higher  level  nesting  for  these  languages. 

The  result  of  the  above  CDS  transformations  yields  a new  data  structure 
which  also  conforms  to  the  CDS  format.  Therefore,  the  denesting  process 
simply  transforms  one  CDS  into  another  CDS  which  is  more  appropriate  to 
the  target  language. 

In  practice  it  does  not  appear  to  be  necessary  to  have  the  transformed 
CDS  available  in  its  entirety.  Instead,  the  original  CDS  can  be  traversed 
in  hierarchical  fashion  and  a set  of  stacks  can  be  maintained  to  handle 
the  "most  local  definition"  and  other  hierarchical  problems.  The  secondary 
CDS  can  be  generated  "on  the  fly"  with  the  final  target  translation  occurring 
in  synchronism  with  the  creation  and  destruction  of  the  dynamic  secondary 
CDS,  The  final  translation  will  utilize  a mixture  of  semantic  trans- 
formations and  syntax  directed  translations  coupled  with  the  parse  of  the 
target  language  CDS . 

Several  details  must  be  addressed  during  the  denesting  process.  It 
is  necessary  to  generate  internal  names  because  of  replication,  denesting, 
movement  of  definitions,  etc.  These  names  may  be  somewhat  arbitrarily 
chosen  for  internal  purposes,  although  they  should  be  related  to  the 
nest  notation  used  in  CSL.  However,  such  names  are  unsatisfactory  as 
final  names  in  the  target  language  because  of  lexical  rules  for  character 
content  and  length  for  indentifiers  in  the  target  languages.  Thus,  there 
are  requirements  for  three  naming  conventions  for  an  item:  the  original 

CSL  name,  the  internal  nam<4 associated  with  the  denested  version,  and 
the  target  language  name.  Attention  must  be  given  to  naming  conflicts  in 
the  target  language. 
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U.  PUSH  DOWN  STACKS  FOR  DENESTING 


A requirement  exists  for  multiple  pushdown  stacks  to  facilitate  the 
denesting  process.  These  are  required  for  associating  terminal  nodes, 
formal  parameters,  micro  substitutions,  and  "most  local  definitions"  with 
a particular  level  in  the  hierarchy. 

A pointer  is  assigned  as  the  primary  linkage  between  a hierarchical 
entity  and  its  associated  push  down  list.  The  pointer  accesses  a linked 
list  which  is  used  to  implement  the  push  down  stack.  The  top  cell  of 
the  stack  contains  the  most  local  information.  The  list  is  doubly  threaded 

to  permit  easy  popping  of  a hierarchical  level  off  the  stack.  The  list 

contains  a pointer  to  a data  cell  which  contains  the  actual  data  of 
interest.  This  data  cell  may  be  of  arbitrary  structure. 

The  push  down  stack  cell  is  a U-tuple  with  the  following  structure; 

1 Ptr  to  next  more  global  cell 

2 Ptr  to  next  cell  on  this  hierarchical  level 

3 Ptr  to  data  cell  associated  with  this  stack  cell 

U Spare  for  arbitrary  linkage 

Let  us  show  an  example  of  the  application  of  the  push  down  stack. 

We  will  apply  the  stack  to  the  "most  local  definition"  problem  associated 
with  assigning  values  to  circuit  elements  in  nested  BOUNDS  entries.  We 
have  the  following  CSL  statement  of  the  problem: 

BOUNDS 

RU  Data  B 

R1  Data  A 

R3  Data  B 

END 

RUN 

BOUNDS 

R1  Data  C 
R2  Data  D 
RU  Data  C 
END  RUN 


86 


Here  we  have  POUNDS  information  given  for  resistors  Rl,  R2,  R3,  and  RU. 
ilie  BOUNDS  lata  is  specified  by  Data  A,  Data  B,  Data  C,  and  Data  D.  The 
global  BOUNDS  information  is  superseded  for  Rl  and  RU  by  a more  local 
definition  during  execution  of  the  RUN  step.  We  will  associate  the 
global  definition  with  level  1,  and  the  RUN  step  definition  with  level  2. 

We  will  use  the  fourth  word  of  the  cell  U-tuple  to  store  a pointer  to  the 
element  description  cell.  In  turn,  each  element  description  cell  will 
contain  a pointer  to  the  push  down  stack  for  that  element.  The  push  down 
3‘acks  are  linked  by  level  as  well  as  from  element  to  element  for  a given 
level.  The  BOUNDS  data  is  stored  in  a set  of  separate  data  cells.  A linked 
list  header  is  established  for  each  of  the  levels.  A value  of  0 is  used 
to  terminate  a pointer  chain. 

Figure  h shows  the  push  down  sta'’k  configuration  when  the  RUN  entry 
is  active  during  denesting. 

5.  COUPLING  OF  THE  CANONIC  DATA  STRUCTURE  TO  THE  TARGET  LANGUAGE 

The  CDS  consists  of  a set  of  nodes  which  are  organized  into  a tree 
structure.  Each  node  contains  linkages  to  other  nodes  of  the  tree  as 
well  as  actual  data.  We  require  a means  of  intelligently  traversing 
the  CDS  and  generating  a set  of  lexical  symbols  which  can  be  used  to 
construct  the  target  language  text.  A simple  blind  traversal  of  the  CDS 
is  unsatisfactory  because  of  the  dissimilarity  in  the  data  structure  of 
the  individual  nodes. 

We  construct  a grammar  using  BNF  notation  which  represents  all  of 
the  "sentences"  which  can  be  formed  by  intelligent  traversals  of  the  CDS. 

We  then  perform  the  intelligent  traverse  (as  described  below),  extracting 
lexical  symbols  from  the  CDS.  These  symbols  are  parsed  by  an  LR  parser, 
using  the  BNF  tables  for  the  CDS  grammar. 

Since  we  now  have  the  capability  of  recognizing  productions  of  the 
CDS  grammar,  we  also  have  the  capability  of  associating  semantic  translations 
and  syntax  directed  translations  with  these  productions.  Thus,  we  are 
able  to  produce  an  output  string  representing  the  target  text  as  a direct 
byproduct  of  parsing  the  CDS. 
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Example  Push  Down  Stack  For  Denesting 


The  lexical  analyzer  and  its  component  scanners  are  not  required  when 
parsing  the  CDS.  Therefore,  we  specify  scanner  0 in  the  lexical  analyzer; 
this  bypasses  the  normal  lexical  analysis  and  relies  upon  the  character 
generator  to  produce  the  required  lexical  and  semantic  codes. 

The  character  generator  is  permitted  to  perform  arbitrary  operations. 

It  will  obtain  lexical  and  semantic  symbols  from  two  sources:  1)  the 

lexical  pair  list  for  text  strings  which  are  available  through  the  CDS,  and 
2)  the  semantic  routines  which  have  been  previously  executed  in  association 
with  the  parser  action.  These  semantic  routines  will  be  capable  of 
generating  lexical  and  semantic  symbols  derived  from  inspection  of  the  CDS. 
These  symbols  are  queued  for  the  character  generator  which  subsequently 
delivers  them  back  to  the  parser.  The  lexical  symbols  then  control  the 
course  of  the  parse  which  in  turn  initiates  other  semantic  routines  which, 
in  turn,  generate  additional  lexical  and  semantic  symbols.  Thus  the 
operation  is  bootstrapped,  guided  by  the  contents  of  the  CDS  through  the 
semantic  routines.  It  is  highly  desirable  that  the  grammar  for  the  CDS 
be  LR(0)  to  avoid  lookahead  problems  on  the  lexical  symbols,  since  the 
lexical  symbols  are  being  generated  Just  ahead  of  their  use  by  the  parser. 

The  purpose  of  employing  the  formal  parsing  technique  in  this  phase 
of  the  translation  is  to  permit  the  formal  specification  of  the  CDS 
grammar  and  the  syntax  directed  translations.  In  this  way,  a formal 
coupling  to  the  BNF  of  the  target  language  is  achieved. 

Since  the  CDS  consists  of  a finite  number  of  node  types  it  is  desirable 
to  assign  particular  semantic  routines  to  processing  particular  CDS  node 
types.  Within  the  processing  of  a node  there  may  be  many  steps;  furthermore, 
the  step  sequence  may  be  interrupted  due  to  a traversal  farther  down  into 
the  CDS  tree.  We  assign  a set  of  states  to  the  semantic  routines  which 
process  each  node  type;  these  states  indicate  the  status  of  processing 
for  the  node.  A pushdown  stack  is  maintained  which  stores  the  semantic 
routine  number  (and  thus  the  node  type)  and  the  current  processing  state 
for  that  node  when  the  processing  is  interrupted.  Now  we  are  able  to 
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recover  the  processing  status  of  a node  as  higher  levels  of  the  CDS  tree 
are  regained.  This  technique  also  permits  recursive  processing  on  a given 
node  type. 

From  the  above  discussion  it  can  be  seen  that  the  CDS-target  language 
coupling  mechanism  depends  upon  two  deterministic  pushdown  automatons 
operating  in  coroutine  fashion,  utilizing  a BIfF  grammar  description  and 
the  CDS  for  control  of  the  operation.  Auxiliary  data  structures  can  be 
generated  as  needed  during  the  parsing  operation.  The  modularity  of  the 
system  permits  very  complex  translations  with  very  few  basic  translating 
routines . 
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I SECTION  VII 

CONCLUSIONS  AND  RECOMMENDATIONS  FOR 
SPECIFIC  TRANSLATION  DETAILS  AND  PROBLEMS 

This  section  discusses  CSL  translation  details  and  indicates  several 
problem  areas  associated  with  translation. 

The  CSL  Translator  should  meet  two  different  goals.  First,  given  a 
description  of  a problem  in  CSL,  it  is  reasonable  to  expect  that  the 
translator  can  produce  the  corresponding  target  language  text  so  that  the 
^ same  CSL  problem  description  can  be  run  on  any  of  the  three  target  language 

programs  with  correct  results.  Second,  the  CSL  language  and  the  translator 
should  be  comprehensive  enough  so  that  any  problem  which  can  be  described 
in  a particular  target  language  can  also  be  described  in  CSL. 

The  first  goal  can  be  met  only  if  problems  which  utilize  features  common 
to  all  three  target  languages  are  submitted  to  the  translator.  This  is  not 
a very  large  subset  of  the  problems  which  can  be  solved  by  using  capabilities 
available  in  each  of  the  programs  used  alone.  The  second  goal  can  be  met 
only  by  extending  the  CSL  language  and  the  translator  to  include  capability 
for  describing  the  various  unique  features  of  the  individual  target  languages; 
this  leads  to  redundancy  in  the  language. 

There  are  many  features  which  are  shared  by  the  three  target  languages , 
but  the  techniques  of  describing  problems  using  these  features  are  sometimes 
vastly  different.  A simple  example  will  make  this  point  clear. 

Let  us  take  a current  source  whose  value  is  described  by  a simple  mathe- 
matical expression  involving  symbolic  coefficients.  The  coefficient  values 
are  specified  in  other  statements.  The  coefficients  have  been  represented 
symbolically  because  we  wish  to  change  their  values  at  a later  time  in  the 
calculation.  For  this  example  we  will  use  the  diode  equation  (the  fact  that 
the  diode  equation  is  available  in  SCEPTRE  will  be  overlooked,  since  we 
could  have  used  another  math  expression  which  SCEPTRE  does  not  have  built 
into  it).  Let  us  describe  this  simple  problem  in  the  four  languages: 
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In  CSL: 


J1 ,1-2=IS* ( EXP ( THETA* V(J1 ) )-l ) 

IS=lE-9 

THETA=30 

In  NET-2  (this  will  involve  comp  delay  using  Release  9 of  NET-2); 

II  2 1 P1*(EXP(P2*V(I1) )-l) 

PI  lE-9 
P2  30 

In  SCEPTRE  (this  will  involve  comp  delay  in  SCEPTRE  since  we  are  not  using 
the  diode  equation); 


CIRCUIT  DESCRIPTION 
ELEMENTS 

J1 , 1-2=X1 ( PIS* ( EXP ( PTHETA*VJ1 ) -1 ) ) 
DEFINED  PARAMETERS 


PIS=lE-9 

PTHETA=30 


In  CIRCUS  (no  comp  delay  involved): 

MODELS 

MODEL  NAME=CURRENT  GENERATOR 
EXTERNAL  N0DES=(A,B) 

TOPOLOGY 

J1,A,B 

EQUATIONS 

Jl=IS*(EXP(THETA*V,Jl)-l) 

D ( J1 ,V , J1 )=THETA* ( Jl+IS ) 

RETURN 

END 

END  OF  INPUT 
DEVICES 

DEVICE  NAME  = JGEN,  MODEL  NAME  = CUBRENT  GENERATOR 

SINGLE  VALUED  PARAMETERS 

IS=lE-9 

THETA=30 

END  OF  INPUT 

PREFIX ,JG, CURRENT  GENERATOR 
JG1,1»2,JGEN 

Note  that  in  translating  to  CIRCUS  that  the  translator  must  also 
determine  the  partial  derivatives  for  the  math  expression  and  sequence  the 
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equations  in  proper  order  in  the  EQUATIONS  section.  Thus,  a translation 
to  CIRCUS  can  certainly  be  specified,  but  implementing  it  is  very  complex. 

A mechanism  for  generating  the  partial  derivatives  for  CIRCUS  is  discussed 
later  in  this  section. 

NET-2  contains  many  specialized  elements  which  have  no  counterpart  in 
the  other  languages.  For  example,  in  order  to  use  the  system  analysis 
capability  of  NET-2  through  the  CSL  language,  it  is  necessary  to  have  CSL 
elements  available  which  permit  access  to  all  of  the  system  elements  in 
NET-2.  However,  translation  of  a problem  using  these  elements  in  the  other 
langueiges,  although  possible,  is  extremely  difficult.  In  general,  it  involves 
having  the  translator  write  special  subroutines  and  automatically  interfacing 
these  routines  with  the  target  simulation  code  in  order  to  accomplish  a 
satisfactory  translation.  It  is  felt  that  such  an  approach  is  outside  of  the 
scope  of  the  translator  project,  although,  from  the  user's  point  of  view  he 
may  consider  it  a reasonable  thing  for  the  translator  to  do.  Accordingly,  a 
basic  guideline  has  been  adopted  that  the  CSL  Translator  will  not  be  concerned 
with  modeling  of  elements. 

1.  SYNTAX  DIRECTED  TRANSLATION 

Much  of  the  target  language  text  can  be  generated  by  means  of  a syntax 
directed  translation  (SDT).  A SDT  builds  and  concatenates  output  text 
strings  by  means  of  specified  linear  transformations  involving  symbols 
associated  with  the  grammar  during  the  parsing  process.  If  semantic  routine 
interfaces  are  permitted  before  executing  a SDT  for  a given  production, 
the  semantic  routine  can  supply  any  arbitrary  or  missing  components  which 
will  be  required  by  the  SDT.  In  this  way  strings  of  any  complexity  cem 
be  constructed  and  placed  in  the  output  stream. 

We  will  exhibit  the  application  of  SDT  for  a number  of  network  elements 
below.  The  translation  for  each  element  will  use  the  BNF  notation  for  the 
original  CSL  format  end  the  three  SDTs  for  the  target  languages.  The  basic 
BNF  and  SDT  notation  is  that  used  by  the  LR(k)  Parser  Generator  described 
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in  Appendix  B of  this  report,  except  that  the  individual  SDTs  will  be  listed 
on  separate  lines  according  to  the  target  language  for  each  element. 

For  the  resistor: 

CSL:  RELEM  = $R$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE 

NET;  RELEM  = $R$  IDA  B NODE  B NODE  B VALUE 

SCEPTRE:  RELEM  = $R$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE 

CIRCUS:  RELEM  = $R$  IDA  $,$  NODE  $,$  NODE  $,$  VALUE 

In  the  above,  IDA  is  an  alphameric  string  beginning  with  a digit  and  B is  a 
blank.  The  translations  for  NODE  and  VALUE  will  have  been  provided  by 
another  production  which  defines  these  nonterminal  symbols.  From  the  above 
we  see  that  the  mapping  requires  no  permutation  of  nonterminal  symbols  by 
any  of  the  SDTs.  The  translation  for  capacitors  is  identical  to  that  for 
resistors  except  that  the  terminal  $C$  replaces  $R$. 

For  current  sources : 

CSL:  JELEM  = $J$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE 

NET:  JELEM  = $1$  IDA  B N0DE(2)  B NODE(l)  B VALUE 

SCEPTRE:  JELEM  = $J$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE 

CIRCUS:  JELEM  = $J$  IDA  $,$  NODE  $,$  NODE  $,$  VALUE 

Here  we  note  that  the  node  order  is  interchanged  when  translating  from  CSL 
to  NET-2.  Also,  the  element  prefix  is  changed  when  translating  to  NET. 

For  voltage  sources ; 

CSL:  VELEM  = $V$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE  $,$  VALUE 

NET:  VELEM  = $V$  IDA  B NODE  B NODE  B VALUE  $,$  VALUE 

SCEPTRE:  VELEM  = $E$  IDA  $,$  N0DE(2)  $-$  NODE(l)  $=$  VALUE 

CIRCUS:  VELEM  = $V$  IDA  $,$  NODE  $,$  NODE  $,$  VALUE 

Here  we  note  that  CSL  may  specify  a second  value  field  representing  series 
resistance.  This  resistance  value  is  easily  translated  for  NET-2,  but  cannot 
be  handled  by  either  SCEPTRE  or  CIRCUS-2  without  inserting  an  extra  series 
resistor  in  the  network,  thus  introducing  an  additional  node.  On  the  other 
hand,  if  no  series  resistor  is  specified  in  CSL,  this  implies  that  the  series 
resistance  value  is  zero,  creating  nximerical  problems  in  the  NET-2  solution. 
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This  simple  example  illustrates  some  of  the  pitfalls  encountered  in  automatic 
translation. 

For  the  inductor: 

CSL:  LELEM  = $L$  IDA  $,$  IlODE  $-$  NODE  $=$  VALUE  $,$  VALUE 

NET:  LELEM  = $L$  IDA  B NODE  B NODE  B VALUE  $,$  VALUE 

SCEPTRE:  LELEM  = $L$  IDA  $,$  NODE  $-$  NODE  $=$  VALUE 

CIRCUS:  LELEM  = $L$  IDA  $,$  NODE  $,$  NODE  $,$  VALUE 

Here  again  there  is  a basis  problem  in  handling  the  optional  series  resistor 
designation  in  CSL.  The  problem  is  identical  to  that  for  the  voltage  source. 

For  the  mutual  inductive  coupling  element: 

CSL:  KELEM  = $K$  IDA  $,$  LNAME  $-$  LNAME  $=$  KVALUE 

NET:  KELEM  = $K$  IDA  B LNAME  B LNAME  B KVALUE 

SCEPTRE:  KELEM  = $M$  IDA  $,$  LNAME  LNAME  $=$  MVALUE 

CIRCUS:  KELEM  = $K$  IDA  $,$  LNAME  $,$  LNAME  $,$  KVALUEl 

Here  we  must  convert  the  CSL  value  for  coupling  coefficient  into  the  mutual 

inductance  value  for  SCEPTRE  using  the  mathematical  transformation 

MVALUE  = KVALUE/SQRT(L1*L2)  where  LI  and  L2  are  the  values  of  the  two 

inductors  involved.  The  handling  of  this  computation  symbolically  (as  it 

must  be  handled  by  the  translator)  can  be  fairly  involved  if  KVALUE,  LI, 

and  L2  are  specified  as  math  expressions.  Also,  for  CIRCUS,  KVALUEl  = - KVALUE. 

This  exhausts  the  circuit  elements  used  in  SCEPTRE  except  for  source 
derivative  terms,  convolution  kernels,  and  special  math  expressions.  In 
the  elements  which  follow  we  will  be  required  to  synthesize  equivalent 
SCEPTRE  elements,  leading  in  some  cases  to  very  involved  translations. 

For  the  rational  impedance/admittance  element: 

CSL:  ZYELiM  = ZYPFX  IDA  $,$  NODE  $-$  NODE  $«$  NUMBER  $,$  $($  NUMl  $)$  $,$ 

$($  NUMl  $)$ 

CIRCUS:  ZYELIM  = ZYPFX  IDA  $,$  NODE  $,$  NODE  $,$  NUMBER  $,$  $($  NUMl  $)$  $,$ 

$($  NUMl  $)$ 

This  element  is  available  only  for  translation  to  CIRCUS.  The  supporting 
BNF  productions  are: 
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ZYPFX  = $Z$ 

ZYPFX  = $Y$ 

NUMl  = NUMBER  $,$  NUMBER 

NUMl  = NUMl  $,$  NUMBER  $,$  NUMBER 


The  pulsed  voltage  and  current  sources  are  CIRCUS  elements  but  can  be 
included  in  CSL  for  the  convenience  of  CIRCUS  users.  Translation  to  CIRCUS 
is  trivial  but  somewhat  involved  for  the  other  languages: 

CSL;  PVSOURCE  = $PV$  IDA  $,$  NODE  $-$  NODE  $=$  NUMFIELD  EOLC 
PJ SOURCE  = $PJ$  IDA  $,$  NODE  $-$  NODE  $=$  NUMFIELD  EOLC 

NUMFIELD  = NUMBER  $,$  NUMBER  $,$  NUMBER  $,$  NUMBER  $,$  NUMBER  $,$ 
NUMBER  $,$  NUMBER 


where  EOLC  denotes  End  of  Logical  Card. 

NET:  PVSOURCE  = $V$  IDA  B NODE  B NODE  B $TABLE$  IDA  ${TIME)$  EOLC  NUMLIST 

PJSOURCE  = $1$  IDA  B N0DE(2)  B NODEU)  B $TABLE$  IDA  $(TIME)$  EOLC 
NUMLIST 

NUMLIST  = $TABLE$  IDA  EOLC 

T NUMBER(3)  B NUMBER(l)  EOLC 
T NUMl  B NUMBER(2)  EOLC 
T NUM2  B NUMBER(2)  EOLC 
T NUM3  B NUMBER(l)  EOLC 
T NUMU  B $R$  EOLC 

where  NUMl,  NUM2,  NUM3,  euid  NUMU  are  given  by  arithmetic  operations  on  the 
veJ-ues  represented  by  the  lexical  symbols; 

NUMl  * NUMBER(3)  + NUMBER(U) 

NUM2  » NUMl  + NU?4BER(5) 

NUM3  « NUM2  ♦ NUMBER(6) 

NUMl*  » NUMBER(3)  + NUMBER(T) 


and  the  lexical  symbol  T denotes  an  indentation  level.  The  instances  of 
the  lexical  symbol  NUMBER  refer  to  the  ordering  in  the  BNF  production  for 
NUMFIELD  in  the  CSL  grammar. 

SCEPTRE:  PVSOURCE  - $E$  IDA  $,$  N0DE(2)  $-$  NODE(l)  $*T$  IDA  $(AM0D(AMAX(TIME-$ 

NUMBER(3)  NUMBER(T)  $)l  EOLC 

PJSOURCE  » $J$  IDA  $,$  NODE  NODE  $*T$  IDA  ${AM0D(AMAX(TIME-$ 
NUMBER(3)  $,0)),$  NUMBER(7)  $)$  EOLC 
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A string  must  be  generated  for  later  insertion  into  the  FUNCTIONS  section 
of  SCEPTRE  to  define  the  table : 

TABDEF  = $T$  IDA  $=$  NUMBER(3)  $,$  NUMBER(l)  $,$  NUMl  $,$  NUMBER(2)  $,$ 
NUM2  $,$  NUMBER(2)  $,$  NUM3  $,$  NUMBER^)  $,$  NUMU  $,$ 

NUMBER(l)  EOLC 

The  lexical  symbols  NUMl,  NUM2,  NUM3,  and  NUMU  are  derived  through  arithmetic 
operations  in  the  same  way  as  for  the  NET  translation. 

CIRCUS:  PVSOURCE  = $PV$  IDA  $,$  NODE  $,$  NODE  $,$  NUMFIELD  EOLC 

PJSOURCE  = $PJ$  IDA  $,$  NODE  $,$  NODE  $,$  NUMFIELD  EOLC 

The  definition  for  NUMFIELD  for  CIRCUS  is  identical  to  that  for  CSL.  This 

SDT  shows  the  need  for  semantic  routine  processing,  dynamic  string  gener- 

ation outside  of  the  SDT,  and  the  ability  to  use  a nonterminal  in  several 
productions . 


Sine  wave  sources  are  another  CIRCUS  feature  which  can  be  included  as 

CSL  elements.  Translation  to  other  languages  is  not  as  difficult  as  in  the 

case  of  the  pulsed  sources: 

CSL:  SVSOURCE  = $SV$  IDA  $,$  NODE  NODE  $=$  NUMFIELD  EOLC 

SJSOURCE  = $SJ$  IDA  $,$  NODE  $-$  NODE  $=$  NUMFIELD  EOLC 
NUMFIELD  = NUMBER  $,$  NUMBER  $,$  NUMBER  $,$  NUMBER 

NET:  SVSOURCE  » $V$  IDA  B NODE  B NODE  B NUMFIELD  EOLC 

SJSOURCE  = $1$  IDA  B N0DE(2)  B NODE(l)  B NUMFIELD  EOLC 
NUMFIELD  = NUMBER (1)  $+$  NUMBER (2)  $»SIN(6.28318»AMAX(TIME-$ 
NUMBER(3)  $,0)/$  NUMBER(U)  $)$ 

SCEPTRE:  SVSOURCE  = $E$  IDA  $ ,$  N0DE(2)  $-$  NODE(l)  $=$  NUMFIELD  EOLC 

SJSOURCE  = $J$  IDA  $,$  NODE  $-$  NODE  $=$  NUMFIELD  EOLC 
NUMFIELD  * $X$  IDA  $($  NUMBER(l)  $+$  NUMBER(2) 

$»SIN(6.28318«AMAX(TIME-$  NUMBER{3)  $,0/$  NUMBER(U)  $)$ 

CIRCUS:  SVSOURCE  * $SV$  IDA  $,$  NODE  $,$  NODE  $,$  NUMFIELD  EOLC 

SJSOURCE  » $SJ$  IDA  $,$  NODE  $,$  NODE  $,$  NUMFIELD  EOLC 
NUMFIELD  « NUMBER  $,$  NUMBER  $,$  NUMBER  $,$  NUMBER 

CIRCUS  also  contains  a tabular  source  element.  Inclusion  of  this  element 


in  CSL  and  subsequent  trcuislation  can  be  accomplished  as  follows: 


CSL:  TVSOURCE  = $T/$  IDA  $,$  NODE  $-$  NODE  $«$  NUMFIELD  EOLC 

TJSOURCE  = $TJ$  IDA  $,$  NODE  $-$  NODE  $=$  NUMFIELD  EOLC 
NUMFIELD  = NUMBER  $,$  NUMBER 
NUMFIELD  = NUMFIELD  $,$  NUMBER  $,$  NUMBER 

NET:  TVSOURCE  = $V$  IDA  B NODE  B NODE  B $TABLE$  IDA  $(TIME)$  EOLC 

NUMFIELD 

TJSOURCE  = $1$  IDA  B N0DE(2)  B N0DE(1)  B $TABLE$  IDA  $(TIME)$ 

EOLC  NUMFIELD 

NUMFIELD  = $TABLE$  IDA  EOLC  T NUMBER  B NUMBER  EOLC 
NUMFIELD  = NUMFIELD  T NUMBER  B NUMBER  EOLC 

SCEPTRE:  TVSOURCE  = $E$  IDA  $,$  N0DE(2)  $-$  NODE(l)  $=T$  IDA  $(TIME)$ 

EOLC  NUMFIELD  EOLC 

TJSOURCE  = $J$  IDA  $,$  NODE  $-$  NODE  $=T$  IDA  $(TIME)$  EOLC 
NUMFIELD  EOLC 

NUMFIELD  = $T$  IDA  $=$  NUMBER  $,$  NUMBER 
NUMFIELD  = NUMFIELD  $,$  NUMBER  $,$  NUMBER 

CIRCUS:  TVSOURCE  = $TV$  IDA  $,$  NODE  $,$  NODE  $,($  NUMFIELD  $),($  NUMFIELD 

$)$  EOLC 

TJSOURCE  = $TJ$  IDA  $,$  NODE  $,$  NODE  $,($  NUMFIELD  $),($  NUMFIELD 
$)$  EOLC 

NUMFIELD  = NUMBER 

NUMFIELD  = NUMFIELD  $,$  NUMBER 

In  the  above  SDT  the  first  productions  of  NUMFIELD  in  each  language  are 
associated  together,  as  are  the  second  productions.  In  the  CIRCUS  translation 
there  is  a mapping  of  NUMBER  into  NUMFIELD  which  cannot  be  expressed  solely 
through  a finite  SDT.  Specifically,  the  nonterminal  NUMFIELD  appears  twice 
in  each  of  the  CIRCUS  productions  for  TVSOURCE  and  TJSOURCE.  The  appearances 
of  NUMBER  in  CSL  occiir  in  pairs,  with  the  first  member  of  each  pair  assigned 
to  the  first  occurrence  of  NUMFIELD  in  CIRCUS,  and  the  second  pair  member 
assigned  to  the  second  occurrence  of  NUMFIELD  in  CIRCUS.  This  type  of  assign- 
ment is  easily  handled  through  a semantic  routine. 

2.  PARTIAL  DIFFERENTIATION  OF  MATH  EXPRESSIONS 

Partial  differentiation  of  math  expressions  is  required  by  CIRCUS  for 
all  math  expressions  entering  into  the  network  solution  and  by  SCEPTRE  for 
soxirce  elements  under  certain  topological  conditions.  Therefore,  the  CSL 
Translator  must  have  the  ability  of  differentiating  math  expressions  with 
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respect  to  specified  variables.  This  differentiation  can  be  accomplished 
by  means  of  a syntax  directed  translation. 

We  will  describe  the  SDT  using  the  input  notation  for  the  LR(k)  Parser 
Generator.  In  addition  to  the  primary  grammar,  we  have  two  SDTs,  the  first 
representing  the  original  math  expression,  the  second  representing  the 
derivative  of  the  math  expression,  'iliese  translations  will  be  labeled 
1 and  2 for  ease  of  identification.  We  will  assume  differentiation  with 
respect  to  a particular  identifier  x.  The  SDT  specification  is: 

S=E,  1=E,  2=E 
E = AOP  T,  1 = AGP  T,  2 = AOP  T 
E=T,  1=T,  2=T 
E = E AOP  T,  1 = E AOP  T,  2 = E AOP  T 
T = F,  1 = F,  2 = F 

T = T $»$  F,  1 = T $»$  F,  2 = T(l,l)  $**$  F(1,2)  $+$  F(l,l)  $»$  T(l,2) 

T = T $/$  F,  1 = T $/$  F,  2 = $($  F(l,l)  $»$  T(l,2)  $-$  TU,1)  $»$  FU,2) 

$)/$  F(l,l)  $»»2$ 

F = FI,  1 = FI,  2 = FI 

F = FI  $»*$  Fi,  1 = FI  $»»$  FI,  2 = Fl(l,l)  $**$  Fl(2,l)  $»($  Fl(2,l)  $»$ 

Fl(l,2)  $/$  Fl(l,l)  $+ALOG($  Fl(l,l)  $)»$ 
Fl(2,2)  $)$ 

FI  = FUNC  $($  ELIST  $)$,  1 = FUNC  $($  ELIST  $)$,  2 = $($  Y $)$ 

FI  = i,  T1  = i,  T2  = W 

FI  = $($  E $)$,  1 = ${$  E $)$,  2 = $($  E $)$ 

ELIST  = E,  1 = E,  2 = E 

ELIST  = ELIST  $,$  E,  1 = ELIST  $,$  E,  2 = ELIST  E 

In  the  above  we  note  the  symbol  Y in  the  second  translation  for  FI.  The 

function  reference  represented  by  FUNC  $($  ELIST  $)$  is  represented 

textually  by  a string  of  the  form  FUNC (A, , A„,  ....,  A ).  We  may  then  define 

i c n 

Y as  the  symbolic  string  representing  the  expression: 

3A 

Y 3Func  ^ SFunc 

3A  3E  3x 

i ^ ^ 

where  E^  is  the  ith  E of  ELIST  In  translation  2 and  x is  the  differentiation 
veuriable . 


The  symbol  W represents  a value  of  one  if  identifier  i is  the  differentiation 
variable  x,  otherwise  W represents  a value  of  zero.  AOP  represents  the 
terminal  symbols  + and  and  i represents  variable  and  numbers. 
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From  the  above  we  see  that  we  can  symbolically  differentiate  with 
respect  to  any  independent  variable  using  an  SDT,  except  for  a semantic 
routine  intervention  for  the  productions  FI  = i and  FI  = FUNC  $($  ELIST  $)$. 
We  also  require  a differentiation  with  respect  to  each  formal  parameter  of 
all  functions  which  are  referenced. 

The  translation  containing  the  derivative  may  contain  many  superfluous 
one  and  zero  terms  as  well  as  unnecessary  parentheses.  The  one  and  zero 
terms  arise  from  the  translation  of  the  production  FI  = i.  We  now  specify 
a SDT  which  accepts  the  derivative  expressions  as  input  and  cleans  up  the 
superfluous  ones,  zeros,  and  parentheses  pairs.  In  this  specification  we 
let  MOP  represent  both  * and  / characters,  and  use  U and  Z to  represent  1 
and  0 values,  respectively: 

S = ES,  ES 
ES  = El,  El 
ES  = EZ,  $0$ 

ES  = EU,  $1$ 

ES  = E,  E 

El  = T,  T 

El  = EZ  $+$  T,  T 

El  = EU  $+$  TU,  $2$ 

El  = El  $+$  TZ,  El 

EZ  = TZ,  NULL 
EZ  = $+$  TZ,  NULL 
EZ  = EZ  $+$  TZ,  NULL 
EU  = TU,  NULL 
BU  = $+$  TU,  NULL 
EU  = EZ  $+$  TU,  NULL 

EU  = EU  $+$  TZ,  NULL 

ELIST  = ES,  ES 

ELIST  = ELIST  $,$  ES,  ELIST  $,$  ES 
E = $+$  T,  $+$  T 
E = EU  $+$  T,  T $+1$ 

E = El  $+$  TU,  El  $+1$ 

E * El  $+$  T,  El  $+$  T 
E = E $♦$  TZ,  E 
E = E $+$  TU,  E $+1$ 

E ■*  E T , E T 
T ■ F,  F 

T » T MOP  F,  T MOP  F 
T a T MOP  FU,  T 
T « TU  MOP  F,  F 
TZ  a FZ,  NULL 


TZ  = T MOP  FZ,  NULL 
TZ  = TU  MOP  FZ,  NULL 
TZ  = TZ  MOP  F,  NULL 
TZ  = TZ  MOP  FZ,  NULL 
TZ  = TZ  MOP  FU,  NULL 
TU  = FU,  NULL 
TU  = TU  MOP  FU,  NULL 
F = FI,  FI 

F = FI  $»»$  FI,  FI  $*»$  FI 

F = FI  $»*$  FUl,  FI 

FZ  = FZl,  NULL 

FZ  = FZl  $**$  FI,  NULL 

FZ  = FZl  $*»$  FUl,  NULL 

FU  = FUl,  NULL 

FU  = FI  $«»$,  NULL 

FU  = FZl  $»*$  FZl,  NULL 

FU  = FUl  $»»$  FI,  NU’ 

FU  = FUl  $*»$  FZl,  JL 
FU  = FUl  $*»$  FUl,  NULL 
FI  = i,  i 

FI  = $($  E $)$,  ${$  E $)$ 

FI  = FUNC  $($  ELIST  $)$,  FUNG  $($  ENLIST  $)$ 

FI  = $($  El  $)$,  El 

FZl  = Z,  NULL 

FZl  = $($  EZ  $)$,  NULL 

FUl  = U,  NULL 

FUl  = ${$  EU  $)$,  NULL 

In  the  above  SDT  the  symbol  NULL  denotes  that  there  is  no  translation 
generated  by  the  corresponding  production.  The  above  SDT  does  not  include 
operations  involving  the  arithmetic  symbol  extension  to  include  this 
symbol  is  trivial. 

Additioneil  cleanup  of  differentiated  expressions  can  be  attained  by  ' 

arithmetically  combining  numerical  constants  and  removing  any  superfluous 
parentheses  which  might  result  from  that  operation.  An  SDT  is  given  below 
which  accomplishes  this.  In  this  SDT  terms  may  be  represented  either  as 
lexical  symbols  or  as  numerical  values.  Semantic  routines  are  required  at 
certain  steps  to  convert  terms  from  symbolic  to  nximerical  form,  from  numerical 
to  symbolic  form,  and  to  perform  arithmetic  operations  on  numerical  forms 
yielding  a numerical  result.  These  steps  are  noted  in  the  SDT  which  is  given 
as : 
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S = SE,  SE 
SE  = E,  E 

SE  = EN,  EN  (Note  l) 

SE  = E AOP  EN,  E AOP  EN  (Note  l) 

E = T,  T 

E = AOP  T,  AOP  T 
E = E AOP  T,  E AOP  T 
EN  = TN,  TN 

EN  = EN  AOP  TN,  EN  AOP  TN  (Note  2) 

T = F,  F 

T = T MOP  F,  T MOP  F 
TN  = FN,  FN 

TN  = TN  MOP  FN,  TN  MOP  FN  (Note  2) 

F = FI,  FI 

F = FI  $*»$  FI,  FI  FI 

IN  = FNl,  FNl 

FN  = FNl  $*»$  FNl,  FNl  $»*$  FNl  (Note  2) 

FI  = i , i 

FI  = $($  E $)$,  $($  E $)$ 

FI  = $1$  E AOP  EN  $)$,  $($  E AOP  EN  $)$  (Note  l) 

FI  = FNl  $**$  FI,  FNl  $»»$  FI  (Notes  1,  1<) 

FI  = FI  $**$  FNl,  FI  $»»$  FNl  (Notes  1,  3,  and  U) 

FI  = FUNC  $($  ELIST  $)$,  FUNC  $($  ELIST  $)$ 

FNl  = n,  n 

FNl  = $($  EN  $)$,  EN 
ELIST  = SE,  SE 

ELIST  = ELIST  $,$  SE,  ELIST  $,$  SE 


Notes : 


1.  If  numerical  component  present,  convert  to  symbolic  form. 

2.  If  symbolic  component  present,  convert  to  numerical  form; 
perform  indicated  arithmetic  operation  and  store  result 
as  translation  in  numerical  form. 

3.  Handle  exponent  as  an  integer  if  possible. 

U.  Check  for  special  cases  and  deliver  appropriate  results. 


In  the  above  SDT  the  symbol  i represents  non-numerical  identifiers,  while 
n represents  numerical  values. 

3.  PROBLEMS  ASSOCIATED  WITH  EMBEDDED  TARGET  TEXT 

It  is  desirable  to  have  a means  of  embedding  sections  of  target  text 
in  the  CSL  source  text.  This  provides  a mechanism  for  describing  target 
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language  features  which  are  not  available  in  CSL  or  are  not  handled  by 
the  translator. 

Target  text  can  be  embedded  through  the  ENTER  entry.  This  entry 
specifies  the  target  language  in  which  the  embedded  text  is  written, 
followed  by  the  text,  and  concludes  with  a special  END  card.  For  example: 

ENTER  NET 

R3  A B 3.97*I(C5) 

C5  H K 2.5 
END  NET 

When  the  CSL  Translator  is  translating  to  a particular  target  language 
it  will  include  all  embedded  target  text  which  corresponds  to  the  target 
language  currently  being  addressed  by  the  translator.  Thus,  embedded  text 
can  be  included  for  more  than  one  target  language , with  the  appropriate 
text  being  used  by  the  translator. 

In  most  instances  this  feature  cannot  be  used  without  specifying 
additional  information.  The  problem  arises  in  that  the  embedded  text  is 
not  parsed  by  the  translator,  but  is  simply  passed  to  the  target  text  output 
stream.  Thus,  the  identifiers  which  are  used  in  the  embedded  text  must 
correspond  to  the  identifiers  which  will  be  used  by  the  CSL  Translator  for 
target  text  which  has  been  translated  from  CSL.  Since  these  translator-chosen 
identifiers  may  be  arbitrary  names,  a conflict  arises.  Consider,  for 
example  the  following  mixture  of  CSL  and  embedded  NET  text: 

TN1,2-3=X 
TN2,1-2=Y 
SUBNET, TN,A-B=C 
R1,A-B=1/C 
ENTER  NET 

TDl  3 B IN60U 
END  NET 
END  SUBNET 

END 
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Here  we  see  that  the  embedded  text  specifies  node  B.  We  assume  that  this 
is  the  same  node  B which  is  a dummy  terminal  node  for  subnet  TN  in  CSL. 

The  translator  is  required  to  denest  this  example  since  a formal  parameter 
is  being  passed  across  the  TN  interface.  Thus,  node  B becomes  node  3 and 
node  2 in  the  denested  circuit.  However,  since  the  embedded  NET  text  is 
simply  passed  on  to  thf  output  stream,  there  is  no  way  of  changing  node  B 
to  the  correct  name.  Alternatively,  the  embedded  NET’  text  could  be  parsed 
and  translated;  this  alternative  is  highly  unattractive  since  it  requires 
complete  semantic  interpretation  for  all  three  target  languages. 

This  problem  can  be  alleviated  in  certain  instances  (but  not  for  the 
example  Just  given)  by  permitting  the  user  to  specify  the  names  to  be  used 
in  the  target  text.  This  is  done  by  including  an  EQUIVALENCE  entry  on  the 
global  level  in  the  CSL  text.  This  entry  has  the  format: 

EQUIVALENCE,  s = t.  , s^  = t_,  s = t 

112  2 n n 

where  s^,  etc.  = the  identifier  name  in  CSL  notation  as  referenced  globally, 
t^,  etc.  = corresponding  identifier  name  in  target  text  to  be  used. 

In  this  way  the  user  can  control  the  assignment  of  names.  B'or  example: 

EQUIVALENCE,  TNl.Rl  = RlOl,  TN2.R1  = R201 

Problems  still  exist  even  with  this  feature.  For  example,  suppose  that 
R1  is  both  an  element  name  and  a node  name  in  subnet  TN;  then  what? 

Another  difficxilty  is  that  of  association  of  the  embedded  target  text 
with  the  correct  location  in  the  output  text  stream.  For  example,  the 
relative  location  of  the  embedded  text  in  the  source  text  cannot  be  used 
reliably,  since  situations  can  arise  where  a single  embedded  text  line 
must  be  associated  with  more  than  one  location  in  the  target  text  stream. 

For  example : 

BOUNDS 

ENTER  NET 

R3  RECT  .2  .6 

END  NET 
R2  = .5,  .8 
END 

RUN  MONTECARLO 
RUN  OPTIMIZATION 
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In  translating  to  NET  the  embedded  text  line  must  be  associated  with  both 
the  Monte  Carlo  and  optimization  solutions.  There  appears  to  be  no  easy 
way  of  resolving  the  location  association  problem  for  embedded  target  text. 

U.  MISCELLANEOUS  CONSIDERATIONS  IN  TRANSLATING  CSL  TO  NET-2 

Listed  below  are  various  miscellaneous  details  which  must  be  considered 
when  implementing  a translation  from  CSL  to  NET-2.  Many  of  the  details  are 
easily  solved,  others  present  more  serious  difficulties. 

1.  The  indentation  level  structure  of  NET-2  must  be  created. 

2.  All  comment  cards  must  be  moved  to  indentation  level  0 in  NET-2. 

3.  Datum  node  definitions  require  that  translation  to  node  0 occur  for 
the  specified  datum  nodes.  If  a datum  node  is  nested,  dummy  terminal 
nodes  must  be  added  to  the  subnetwork  interfaces  in  the  nest  to  provide 
a route  back  to  the  global  node  0. 

4.  Order  of  node  names  must  be  permuted  for  certain  elements. 

5.  Complex  sources  cannot  be  translated  to  NET-2. 

6.  Subnetwork  definitions  are  translated  to  the  NET-2  DEFINE  entry,  retaining 
as  much  information  as  possible.  However,  TABLE,  CURVE,  and  BOUNDS 
entries  are  not  allowed  within  DEFINE  entries  and  must  be  removed. 

7.  NET-2  cannot  handle  procedures. 

8.  Initial  conditions  are  built  into  certain  element  specifications  in 
NET-2.  Where  applicable,  they  must  be  transferred  from  the  CSL  INITIAL 
CONDITIONS  entry  to  the  appropriate  element  description.  If  the  initial 
conditions  change  they  must  be  represented  symbolically  in  NET-2. 

9.  Real  variables  which  have  a specified  numerical  constant  value  are 
translated  to  P constants. 

10.  Real  variables  which  are  defined  symbolically  are  translated  to  X 
variables . 

11.  Element  parameter  symbols  must  be  translated  to  sequence  numbers  for 
elements  which  are  not  handled  as  modeled  devices  in  NET-2. 

12.  CSL  fxinction  names  must  be  converted  to  NET  names  by  prefixing  FI  to 
the  name. 


13.  The  sensitivity  function  is  not  available  in  NET-2. 

li* . The  value  modifiers  PT,  PV,  and  TV  are  not  available  in  NET-2. 

15.  Time  derivatives  of  real  variables  are  translated  to  the  corresponding 

X'  variable. 

16.  Time  integral  values  require  a prescan  of  the  CSL  real  variable 
equation  system  so  that  the  appropriate  real  variables  can  be  trans- 
lated as  X'  variables.  A conflict  may  exist  in  that  the  time  derivative 
and  time  integral  of  a real  variable  may  be  required. 

17.  Math  expressions  may  not  be  used  for  parameter  value  changes. 

18.  BOUNDS  entry  information  must  be  incorporated  inside  of  the  Monte  Carlo 

entry. 

19.  The  CURVE  entry  must  be  translated  to  a DIST  entry,  ignoring  any  weights, 
for  use  by  the  Monte  Carlo  solution. 

20.  The  nominal  solution  translates  to  a STATE  entry.  Run  controls  are 
not  allowed. 

21.  Only  small  signal  transfer  functions  of  the  form  xM  and  xD  (where  x is 
A,  B,  Y,  or  Z)  are  allowed. 

22.  Output  labels  cannot  be  accommodated. 

23.  BOUNDS  entry  information  must  be  incorporated  within  the  optimization 
solution. 

2h.  Math  expressions  are  not  allowed  within  the  STATE  entry  except  in  the 
specification  of  an  objective  function. 

25.  Worst  case  solution  is  not  allowed. 

26.  Out  of  bounds  values  in  tables  are  handled  by  extension  of  boundary 
value  in  NET-2  as  opposed  to  extension  of  boundary  slope  in  CSL.  Tables 
must  be  fixed  up  to  allow  reasonable  out  of  bounds  capability.  This  is 
non-trivial  for  two-dimensional  tables. 

5.  MISCELLANEOUS  CONSIDERATIONS  IN  TRANSLATING  CSL  TO  SCEPTRE 

Listed  below  are  various  miscellaneous  details  which  must  be  considered 

when  implementing  a translation  from  CSL  to  SCEPTRE.  Memy  of  the  details  are 

easily  solved,  others  present  more  serious  difficulties. 
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1.  All  translated  text  must  be  organized  under  the  SCEPTRE  headings  of 

MODEL  DESCRIPTION,  CIRCUIT  DESCRIPTION,  and  RERUN  DESCRIPTION. 

2.  Comments  must  be  relocated  to  immediately  follow  a heading.  Only  11 
comment  cards  permitted  for  each  heading. 

3.  Names  must  be  restricted  in  length  according  to  SCEPTRE  rules.  Care 
must  be  taken  in  choosing  target  names  to  insure  uniqueness  and  retain 
meaning. 

U.  SCEPTRE  does  not  have  a global  datum  node.  A node  must  be  specified 
as  the  effective  datum. 

5.  Only  a limited  set  of  electrical  elements  are  available.  Other  CSL 
elements  must  be  modeled;  this  can  become  very  complex. 

6.  Source  derivative  expressions  must  be  provided  under  certain  topological 
conditions. 

7.  Small  signal  transfer  functions  are  not  permitted. 

8.  CURVE  entry  has  no  SCEPTRE  counterpart. 

9-  Procedures  must  be  converted  to  FORTRAN  functions  or  subroutines. 

10.  Math  expressions  defining  element  values  must  be  converted  to  SCEPTRE 
expression  format. 

11.  Real  variables  translate  to  defined  parameters  and  their  time  derivatives. 
A prescan  is  necessary  to  determine  whether  a real  veuriable  should 
become  a defined  parameter  or  the  associated  time  derivative.  Conflicts 

may  arise  due  to  the  requirement  for  both  the  time  integral  and  the 
time  derivative  of  a real  variable. 

12.  Functions  must  be  converted  to  SCEPTRE  equation  format,  with  equation 
definitions  placed  under  the  FUNCTIONS  subheading. 

13.  CSL  names  which  occur  in  procedures  and  functions  which  are  unacceptable 
to  FORTRAN  must  be  replaced  and  entered  via  the  formal  parameter  list. 

lU.  Two-dimensional  tables  are  not  permitted. 

15.  I and  V are  the  only  permitted  time  domain  reponse  variables. 

16.  Math  expressions  cannot  be  used  to  specify  parameter  value  changes. 

17 • Problems  occur  in  translating  CSL  parameter  control  information  such 
as  swept  and  parametric  variable  value  specification.  This  includes 
control  of  time  step  and  frequency  intervals. 
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APPENDIX  A 
LR(k)  PARSING 

LRfk)  parsing  is  a bottom-up  parsing  method  in  which  input  text  is 
scanned  from  ^eft  to  right  (the  L part),  the  rightmost  sentential  form 
is  always  reduced  (the  R part),  and  at  most  k symbols  of  lookahead  are 
required  to  resolve  ambiguities  which  may  arise  during  the  parse  (the  k 
part).  LR(k)  parsers  are  able  to  parse  languages  describable  by  LR(k) 
grammars,  which  include  a large  subset  of  the  class  of  context  free 
, grammars.  Virtually  all  computer  languages  in  use  today  can  be  described 

by  context  free  grammars  (and,  in  some  cases,  by  regular  grammars,  which 
are  special  cases  of  the  context  free  grammars).  In  addition,  LR(k) 
parsers  process  text  in  a time  proportional  to  the  length  of  the  text 
string  and  never  backtrack.  Practical  parsers  are  deterministic  and 
are  guaranteed  to  detect  and  announce  syntajc  errors  immediately  upon 
j encountering  them. 

From  the  above  remarks  it  can  be  seen  that  LR(k)  parsing  riethods 
have  many  advantages  and  virtually  no  disadvantages  compared  to  other 
parsing  methods.  In  the  past,  LR(k)  parsers  have  had  a serious  dis- 
advantage in  that  the  tables  required  to  direct  the  parse  were  extremely 
large,  even  for  a small  grammar.  Recent  advances  in  implementing  LR(k) 
parsers  have  lead  to  a substantial  reduction  in  table  size,  much  of  the 
reduction  being  due  to  packing  and  optimization  techniques.  The  LR(k) 
parser  which  has  been  developed  for  the  CSL  Translator  takes  advantage 
of  these  techniques. 

Basically,  ein  LR(k)  parser  operates  by  scanning  lexical  symbols 
representing  the  input  text  and  storing  a histoiry  of  the  parse  in  a 
pushdown  stack.  Thus,  it  operates  as  a finite  pushdown  automaton.  By 

j 

j means  of  a lookahead  capability  it  is  possible  to  make  the  parse  com- 

pletely deterministic  at  every  stage. 
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It  is  useful  to  develop  the  LR(k)  parser  in  terms  of  a finite 
state  machine  without  a pushdown  stack  initially.  We  will  then  add 
the  pushdown  stack  which  will  permit  the  LR(0)  languages  to  be  parsed. 
Finally,  the  lookahead  capability  will  be  added  permitting  the  LR(k) 
languages  to  be  parsed. 

1.  THE  CHARACTERISTIC  FINITE  STATE  MACHINE 

We  will  begin  the  development  of  an  LR(k)  parser  by  building  a 
characteristic  finite  state  machine  (CFSM).  We  assume  that  any  sentence 
in  the  language  which  is  to  be  parsed  is  always  terminated  by  a special 
end  symbol  $.  The  grammar  may  contain  left  and  right  recursive  pro- 
ductions. We  choose  for  purposes  of  illustration  the  following  grammar 
which  describes  simple  mathematical  expressions: 

1 S = E $ 

2 E = T 

3 E = E + T 

1+  T = F 

5 T = T * F 

6 F = i 

7 F = (E) 

where  the  terminal  symbols  are  $ , + , * , i , ( , and  ) . We  niunber  the 
productions  with  the  integers  1 through  7.  We  will  also  number  the 
symbols  on  the  right  hand  side  of  each  production  from  left  to  right, 
starting  with  the  number  1.  We  further  assume  that  each  production  has 
a special  terminal  symbol  # appended  to  its  right  end. 

We  can  specify  ordered  pair  m,n  which  permits  us  to  designate  a 
particular  term  in  production  m,  term  n.  Thus,  term  1,2  is  the  symbol  $. 

Let  us  now  establish  the  CFSM  by  creating  em  initial  state,  SI.  We 
will  initialize  SI  with  all  first  terms  of  all  productions  which  define 
the  grammar  goal  symbol  (in  this  case  term  1,1  since  the  grammaur  goal 
symbol  S is  defined  only  by  production  l).  We  cein  specify  a CFSM  state 
and  the  production  terms  of  \rtiich  it  is  composed  by  listing  the  CFSM 
state  number,  the  production  and  term  number,  and  the  grammar  symbol 
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which  corresponds  to  that  production  and  term.  Thus  we  have  initialized 
the  state  SI  as  follows: 

SI  1,1  E 

The  information  which  we  have  listed  for  SI  is  called  the  basic  state  of 
SI.  The  basic  state  contains  sufficient  information  to  show  us  exactly 
where  we  are  at  some  given  point  in  the  parse.  If  the  basic  state  contains 
only  terminal  symbols,  then  the  basic  state  is  the  complete  CFSM  state. 
However,  if  the  basic  state  contains  nonterminal  symbols,  as  is  the  case 
in  SI  in  the  example,  then  each  nonterminal  symbol  represents  one  or  more 
productions  which  can  be  added  to  the  CFSM  state,  with  each  new  production 
represented  by  the  first  symbol  of  that  production.  Again,  if  a new  non- 
terminal is  introduced  into  the  CFSM  state,  the  state  is  again  augmented 
by  the  first  symbol  of  all  productions  defined  by  that  nonterminal.  This 
process  continues  until  no  new  productions  can  be  added  to  the  state,  at 
which  time  the  state  is  complete.  Thus,  expanding  the  basic  state  for  SI 
we  find  the  complete  state  for  SI  to  be; 

SI  1,1  E 

2.1  T 

3.1  E 
U,1  F 

5.1  T 

6.1  i 

7.1  ( 

The  underline  is  used  to  delineate  the  basic  state  from  the  complete 
state.  We  note  that  the  details  of  expansion  for  the  above  state  are  as 


follows : 

1. 

The  basic  state  is  1,1  E. 

2. 

E is  a nonterminal  and  introduces  productions  2 and 
fore  augment  SI  with  terms  2,1  T and  3,1  E. 

3. 

We  there 

3. 

2,1  T is  a nonterminal  represented  by  productions  U 
therefore  augment  SI  with  terms  U,1  F and  5,1  T. 

and 

5.  We 
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1+.  3,1  E is  a nonterminal,  but  all  productions  for  E have  already 

been  included  in  SI,  therefore  there  is  no  further  action  asso- 
ciated with  this  term. 

5.  1+,1  F is  a nonterminal  represented  by  productions  6 and  7.  We 

therefore  augment  SI  with  terms  6,1  i and  7,1  (. 

6.  5,1  T is  a nonterminal  which  has  previously  been  accounted  for, 
therefore  there  is  no  further  action  associated  with  this  terra. 

7.  6,1  i is  a terminal  symbol,  therefore  no  further  action  is 

/ 

associated  with  this  term. 

8.  7,1  ( is  a terminal  symbol,  therefore  no  further  action  is 

associated  with  this  term. 

We  note  that  the  state  SI  shows  the  terms  in  the  grammar  which  are 
currently  involved  in  the  reading  of  the  terminal  symbols  contained  in 
the  state.  That  is,  we  will  read  either  an  i or  ( symbol  at  this  stage 
of  the  parse;  this  in  turn  means  we  are  in  the  process  of  forming  the 
nonterminals  represented  by  1,1;  2,1;  3,1;  U,l;  and  5,1.  Also,  since 
this  is  the  initial  state,  we  are  in  the  process  of  initiating  the 
grammar  goal  production.  Thus,  the  CFSM  state  specifies  exactly  where 
we  are  in  the  parsing  process. 

Each  nontermina?.  or  terminal  symbol  except  # in  a state  is  followed 
by  a subsequent  symbol  which  is  a member  of  another  state,  called  the 
destination  state  for  the  nonterminal  or  terminal  symbol.  That  is,  when 
a terminal  symbol  has  been  read  and  recognized,  or  a nonterminal  construct 
has  been  completed,  a transition  to  a new  CFSM  state  is  made.  This  permits 
us  to  define  the  next  CFSM  state  S2.  We  will  assign  S2  as  the  destination 
state  for  the  nonterminal  E in  state  SI.  That  is,  whenever  we  have  com- 
pleted the  construction  of  E in  SI  we  will  then  enter  state  S2.  Accordingly, 
we  speak  of  S2  as  the  destination  state  of  E in  state  SI  and  enter  the 
destination  state  in  the  destination  state  column  for  E in  SI.  The  first 
entry  in  SI  now  reads: 

SI  1,1  E S2 
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The  basic  state  of  the  destination  state  can  now  be  defined.  It 
contains  the  successor  tenns  of  the  terms  which  caused  a transition  to 
the  destination  state.  Thus,  in  the  example,  the  basic  state  for  S2 
contains  1,2  (the  successor  to  1,1 ) and  3,2  (the  successor  to  3,1).  However, 
if  the  new  destination  state  basic  state  is  identical  with  a basic  state  of 
a previously  developed  state,  then  the  transition  is  always  made  to  the 
previously  developed  state.  In  other  words,  the  basic  states  define  the 
unique  configurations  of  the  grammar  which  can  occur  during  parsing;  a 
duplication  of  a basic  state  would  destroy  that  uniqueness. 

The  end  of  a production  is  signaled  by  the  appearance  of  the  it  symbol 
as  a term.  In  this  case  there  is  no  expansion  to  other  productions. 

Rather  it  signifies  that  a production  has  been  completed  and  that  a 
reduction  to  the  production  goal  symbol  is  to  occur.  Thus,  there  is 
no  destination  state  associated  with  the  H symbol. 

When  all  nonterminal  transitions  have  been  completed  and  no  new  CFSM 
states  have  been  generated  the  CFSM  is  complete.  The  complete  CFSM  for 
the  example  grammar  is  shown  below: 


SI 

1|1 

E 

S2 

2,1 

T 

S3 

3,1 

E 

S2 

F 

su 

5,1 

T 

S3 

6,1 

i 

S5 

7,1 

( 

S6 

S2 

1,2 

$ 

S7 

3,2 

+ 

S8 

S3 

2,2 

a 

5,2 

m 

S9 

SU 

»*,2 

a 

S5 

6,2 

a 

S6 

Ti2 

E 

SIO 

2,1 

T 

S3 

3,1 

E 

SIO 

•♦,1 

F 

su 

5,1 

T 

S3 

6,1 

i 

S5 

7,1 

( 

S6 
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S7 

1,3 

» 

S8 

3,3 

T 

Sll 

F 

sK 

5,1 

T 

Sll 

6.1 

i 

S5 

7,1 

( 

S6 

S9 

F 

S12 

6,1 

i 

S5 

7,1 

( 

S6 

SIO 

7,3 

) 

S13 

3,2 

+ 

S8 

Sll 

3,U 

5,2 

S9 

S12 

5,J* 

K 

SI  3 

7,U 

ft 

Althoiigh  the  CFSM  enumerates  the  various  configurations  of  the  grammar 
which  may  be  encountered  during  the  course  of  parsing  we  note  that  a 
practical  parser  cannot  be  constructed  using  a CFSM  expansion  for  the 
example  grammar  for  two  reasons . First , we  note  that  in  S3  we  must 
decide  between  reading  a * symbol  and  applying  production  2.  Similar 
problems  occur  in  Sll.  Second,  there  is  not  yet  any  formal  mechanism 
for  knowing  the  destination  state  following  the  application  of  a production. 
The  first  problem  is  solved  by  the  lookahead  process;  the  second  by  adding 
a pushdown  stack  to  create  a pushdown  automaton. 

2.  THE  DETEFy<INISTIC  PUSHDOWN  AUTOMATON 

It  is  necessary  to  convert  the  CFSM  into  a deterministic  pushdown 
automaton  (DPDA)  in  order  to  be  able  to  unambiguously  parse  LR(k)  grammars. 
We  will  describe  the  process  in  two  steps.  The  first  step  will  detail  the 
pushdown  automaton.  The  second  step  will  describe  the  conversion  to  a 
deterministic  pushdown  automaton. 
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We  note  from  our  example  grammar  that  we  require  a means  of  deter- 
mining the  destination  state  for  our  automaton  when  a production  is 
reduced  to  its  goal  symbol.  The  process  of  reducing  a production  to  its 
goal  symbol  is  called  the  application  of  the  production.  Clearly  the 
destination  state  is  known  if  we  know  where  the  production  being  applied 
was  initiated  in  the  CFSM,  since  then  the  destination  would  be  the 
destination  state  for  the  production  goal  symbol  at  that  point  in  the 
CFSM. 

We  introduce  a pushdown  stack  to  save  the  detailed  history  of  the 
parse.  If  we  save  the  CFSM  state  which  is  entered  at  each  step  of  the 
parse , then  clearly  we  have  a detailed  history  of  the  parse  and  can 
determine  in  principle  where  to  make  a transition  in  the  event  of  appli- 
cation of  a production. 

We  now  describe  the  basic  operations  which  our  pushdown  automaton 
can  perform.  We  can  read  a terminal  symbol,  in  which  case  the  symbol  is 
consumed  and  the  input  text  pointer  is  advanced  to  the  next  symbol;  this  is 
called  a read  operation.  We  can  apply  a production,  in  which  case  no 
input  is  read  but  instead  a sequence  of  one  or  more  grammar  symbols  is 
reduced  to  a single  production  goal  symbol.  We  can  enter  an  accepting 
state  which  signals  the  successful  completion  of  parsing  of  the  input 
text  by  a final  reduction  to  the  grammar  goal  symbol.  Finally,  we  can 
enter  an  error  state  because  the  input  symbol  which  has  Just  been  read 
is  unacceptable  to  the  grammar  at  that  point  in  the  parse. 

The  CFSM  states  can  be  divided  into  three  kinds  of  states : read 

states,  apply  states,  and  inadequate  states.  CFSM  states  which  contain 
only  transitions  on  terminal  and  nonterminal  symbols  are  called  read 
states.  CFSM  states  which  contain  only  a single  application  of  a pro- 
duction are  apply  states.  All  other  CFSM  states  eu:e  inadequate  states. 

The  CFSM  becomes  nondeterministic  whenever  an  inadequate  state  is  entered; 
that  is,  it  is  not  known  whether  a new  symbol  should  be  read  or  a pro- 
duction application  should  be  made.  The  nondeterministic  CFSM  states  can 
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be  converted  into  deterministic  states  by  means  of  a lookahead  process 
which  determines  the  correct  action  on  the  basis  of  symbols  yet  to  he- 
re ad. 

We  note  that  input  symbols  are  consumed  only  by  read  states.  Since 
all  possible  symbols  which  can  occur  at  a given  point  in  the  parse  are 
included  in  the  terminal  symbol  set  in  a particular  read  state,  we  see 
that  the  parser  has  the  ability  to  announce  an  error  if  any  symbol  other 
than  those  in  the  read  state  terminal  symbol  set  is  encountered.  Thus, 
the  parser  has  the  ability  of  detecting  a syntax  error  immediately  upon 
encountering  an  incorrect  symbol. 

We  also  note  that  we  can  save  the  history  of  the  parse  on  the  pushdown 
stack  by  pushing  each  read  state  identity  onto  the  stack  as  the  read  states 
are  entered.  We  will  include  the  read  transitions  of  an  inadequate  state 
as  a read  state  associated  with  that  inadequate  state  so  that  the  stack 
may  also  contain  this  read  state  identity. 

Let  us  consider  a production  which  contains  only  terminal  symbols. 

We  note  that  each  terminal  symbol  will  be  read  by  a particular  read 
state.  When  the  If  term  of  the  production  is  encountered,  signifying 
that  the  production  is  to  be  applied,  the  stack  will  have  been  augmented 
by  a number  of  read  state  identities  equal  to  the  number  of  terms  in  the 
production.  When  the  production  is  applied  the  stack  is  popped,  removing 
all  read  state  identities  except  that  corresponding  to  the  first  term  of 
the  production.  This  read  state  identity  remains  on  the  stack  and  repre- 
sents the  nonterminal  symbol  to  which  the  production  is  being  reduced.  As 
the  parsing  continues  this  stack  entry  represents  the  nonterminal  term  in 
some  production  which  initiated  the  production  Just  applied. 

From  the  above  it  can  be  seen  that  the  stack  always  contains  entries 
representing  terms  of  partially  completed  productions  (except  for  the 
top  of  the  stack  which  may  contain  a complete  production  about  to  be 
applied).  Furthermore,  these  uncompleted  productions  extend  back  to 
the  very  start  of  the  parsing  operation.  The  reduction  of  the  top  set  of 
entries  to  a nonterminal  represents  the  reduction  of  the  rightmost  sen- 
tential form  in  the  LR(k)  parsing  process. 
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The  pushdown  stack  provides  the  means  by  which  the  parser  knows 
what  destination  state  to  choose  following  the  application  of  a pro- 
duction. In  developing  the  CFSM  states  we  keep  track  of  the  states  in 
which  each  production  is  initiated.  The  set  of  initiating  states  for  a 
production  are  ^.nown  as  the  top  states  for  that  production.  There  will 
always  be  a read  state  on  the  stack  corresponding  to  an  initiating  state 
for  a production.  When  the  production  is  applied,  the  stack  is  popped, 
removing  all  stack  entries  except  that  corresponding  to  the  read  state 
which  initiated  the  production;  hence  the  name  top  state,  since  the 
initiating  read  state  is  now  on  the  top  of  the  stack. 

Since  the  production  which  has  been  applied  is  known,  we  know  what 
nonterminal  has  been  generated  by  the  production  application.  Since  we 
6ilso  know  the  top  state  which  initiated  the  expansion  of  that  nonterminal 
(i.e..  Initiated  the  production  Just  applied)  we  know  the  destination  state 
for  that  nonterminal.  Thus,  when  a production  is  applied  we  know  immediately 
from  the  top  state  identity  what  the  resulting  nonterminal  destination  state 
is.  This  permits  the  nonterminals  to  be  completely  removed  from  the  parsing 
table,  resulting  in  substantial  savings  in  table  size. 

We  are  now  in  a position  to  describe  the  DPDA  states.  They  are 
generated  from  the  CFSM  states  as  follows : The  terminal  symbol  read 

transitions  of  a CFSM  read  state  comprise  a corresponding  DPDA  read  state. 

The  terminal  read  transitions  of  a CFSM  inadequate  state  comprise  a 
corresponding  DPDA  read  state.  Each  production  application  in  a CFSM 
apply  or  inadequate  state  becomes  a DPDA  apply  state.  CFSM  inadequate 
states  become  DPDA  lookahead  states.  The  initiating  states  for  each 
production  in  the  CFSM  states  become  top  state  identities  for  that 
production  in  the  DPDA. 

Let  us  Illustrate  these  concepts  using  our  example  grammar.  We  will 
label  the  DPDA  states  with  the  letters  R,  A,  and  L,  corresponding  to 
read  states,  apply  states,  and  lookahead  states.  We  will  retain  the 
same  niimbering  for  read  ana  lookahead  states  as  was  used  in  the  CFSM; 


117 


however,  we  will  label  apply  states  with  the  original  production 
numbering  scheme. 

The  read  states  for  the  example  grammar  are: 


R1 

i 

a6 

( 

r6 

R2 

$ 

A1 

+ 

R8 

R3 

R9 

r6 

i 

A6 

( 

R6 

R8 

i 

a6 

( 

r6 

R9 

i 

a6 

( 

r6 

RIO 

) 

A7 

+ 

R8 

Rll 

R9 

The  apply  states  may  be  specified  by  listing,  in  order,  the  apply  state 
identity  using  the  original  production  numbers,  the  number  of  entries  to  be 
popped  from  the  stack  (one  less  than  the  number  of  terms  in  the  production), 
and  the  top  state  vector  identity.  There  is  a top  state  vector  for  each 
unique  nonterminal,  representing  one  or  more  productions  which  reduce  to 
that  nonterminal.  The  top  state  vector  for  a nonterminal  contains  the  DFDA 
read  state  identities  corresponding  to  the  initial  read  state  for  the 
corresponding  production  set.  The  top  state  vector  numbering  uses  the 
original  production  numbering  for  the  first  production  which  defines  a 


particular  nonterminal.  Top  state  identities  are  prefixed  with  a T. 
The  DPDA  apply  states  are ; 


A1 

1 

T1 

A2 

0 

T2 

A3 

2 

T2 

kh 

0 

TU 

A5 

2 

Tli 

A6 

0 

T6 

A7 

2 

t6 

The  top  state  vectors  list,  in  order,  the  top  state  identity,  the 
DPDA  read  state  which  may  occur  as  a top  state,  and  the  destination 
state  corresponding  to  that  top  state.  For  the  example  grammar  we  have; 


T1 

Rl 

0 

T2 

Rl 

R2 

R6 

RIO 

TU 

Rl 

L3 

r6 

L3 

r8 

Lll 

T6 

Rl 

kk 

r6 

kk 

R8 

kh 

R9 

A5 

We  note  that  nonterminal  S is  defined  in  production  1,  therefore  we 
will  have  a top  state  Tl;  similarly,  nonterminal  E is  defined  in  pro- 
ductions 2 and  3,  therefore  we  will  have  a top  state  T2  since  that  is 
the  first  production  defining  E.  Next  we  note  that  the  production  covered 
by  T1  (production  l)  is  initiated  in  CFSM  state  SI,  with  a corresponding 
DPDA  read  state  Rl;  therefore,  T1  has  R1  as  a top  state.  Similarly,  the 
productions  covered  by  tU  (productions  and  5)  are  initiated  in  CFSM 
states  SI,  S6,  and  S8,  with  corresponding  DPDA  read  states  Rl,  R6,  and 
R8;  therefore,  TU  has  top  states  Rl,  R6,  and  r8. 
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Next  let  us  inspect  the  destination  states  in  the  top  state  vector. 

The  destination  state  associated  with  top  state  R1  in  top  state  vector  T1 
is  special;  if  that  production  is  applied  then  we  have  reached  the  grammar 
goal  symbol  and  the  parsing  is  complete;  thus  a special  destination  state  0 
is  reached  which  signals  the  satisfactory  completion  of  the  parsing  operation. 
If  we  use  top  state  vector  T2  we  know  that  we  have  Just  applied  either  pro- 
duction 2 or  3,  resulting  in  nonterminal  E.  If  the  initiating  state  for  the 
production  was  CFSM  SI  (corresponding  to  DPDA  state  Rl),  we  can  see  that 
the  destination  associated  with  E in  SI  is  S2,  which  corresponds  to  a DPDA 
destination  state  R2.  Thus,  in  T1  a top  state  Rl  leads  to  a destination 
state  R2.  In  TU  we  have  applied  either  production  or  5,  resulting  in 
nonterminal  T.  If  the  top  state  is  r8  (corresponding  to  CFSM  state  S8), 
we  see  that  a transition  on  T in  S8  takes  us  to  state  Sll  which  is  an 
inadequate  state.  State  Sll  corresponds  to  DPDA  lookahead  state  Lll. 

Thus,  in  Tit  a top  state  R8  takes  us  to  a destination  state  Lll. 

3.  LOOKAHEAD  STATES 

The  DPDA  will  contain  lookahead  states  whenever  the  CFSM  contains 
inadequate  states.  A lookahead  state  must  examine  the  next  n symbols 
(n  i l)  in  order  to  decide  whether  to  enter  a read  state  or  apply  a 
production.  The  amount  of  lookahead  required  by  each  lookahead  state 
may  be  different,  but  the  greatest  amount  of  lookahead  required  by  any 
lookahead  state  in  an  LR(k)  grammar  is  k symbols.  Thus,  if  the  grammar 
is  LR(0)  no  lookahead  is  required  and  the  DPDA  as  currently  described 
is  adequate  for  parsing  such  a grammar.  Generally,  grammars  do  not  tend 
to  be  more  complex  than  LR ( 3 ) . 

The  basic  problem  in  defining  a lookahead  state  is  to  determine  the 
minimal  sequence  of  lookahead  symbols  which  must  be  examined  in  order  to 
resolve  the  ambiguity.  On  the  basis  of  the  lookahead  string  a transition 
can  then  be  made  either  to  an  apply  state  or  a read  state.  The  lookahead 
algorithm  to  be  described  here  is  applicable  only  to  the  parsing  of  the 
grammar  itself.  When  error  recovery  and  semantic  actions  internal  to  the 
production  are  required,  the  lookahead  process  becomes  more  complex. 
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Basically,  the  lookahead  algorithm  consists  of  a paralle]  expansion 
of  the  possible  transition  paths,  inspecting  as  many  terminal  symbols  as 
may  be  required  to  resolve  the  lookahead  ambiguity.  When  the  parsing 
tables  are  being  generated  there  is  no  specific  input  symbol  string;  thus 
it  is  necessary  to  consider  all  possible  strings  when  developing  the 
lookahead  tables. 

Each  lookahead  state  can  be  initially  separated  into  a set  of  basic 
substates.  Each  basic  substate  is  either  a read  state,  containing  all 
terminal  read  symbols,  or  sin  apply  state  containing  a single  apply  (in 
fact,  the  basic  substates  are  identical  with  the  states  which  are 
immediately  entered  upon  resolution  of  the  lookahead  problem).  Each  of 
the  basic  substates  is  then  expanded  until  the  next  terminal  symbol  is 
read  in  each  expansion.  At  this  point  the  terminal  symbol  string  asso- 
ciated with  each  basic  substate  is  examined  for  uniqueness.  Those  basic 
substates  which  have  unique  strings  have  been  resolved  with  regard  to 
lookahead;  those  basic  substates  which  do  not  have  unique  lookahead 
strings  must  be  extended  further  until  another  terminal  symbol  has  been 
read  and  added  to  the  string.  This  process  is  continued  until  there  is 
a unique  terminal  string  associated  with  each  basic  substate.  The  amount 
of  lookahead  associated  with  a particular  lookahead  state  is  then  the 
length  of  the  longest  string  required  by  the  algorithm  to  separate  its 
basic  substates. 

In  performing  the  expansion  the  following  rules  are  used:  For  read 

states  all  terminal  symbol  transitions  are  employed.  All  top  state 
transitions  are  used  for  apply  states.  Any  lookahead  state  which  is 
encountered  must  be  separated  into  basic  substates  and  they  in  turn  are 
expanded.  Thus,  the  expansion  of  a lookahead  state  may  invoke  additional 
lookahead  states;  the  separation  of  secondary  lookahead  states  into  their 
basic  substates  does  not  require  unique  strings  for  these  substates  how- 
ever. 
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The  lookahead  expansion  is  best  visualized  as  a graph  in  which  the 
root  of  the  graph  is  the  original  lookahead  state,  the  immediate  descendant 
nodes  of  the  root  represent  the  substates , descendants  of  the  substate 
nodes  represent  various  DPDA  states  which  are  encountered  during  the 
expansion,  and  the  branches  represent  transitions  from  state  to  state. 
Branches  which  correspond  to  read  transitions  on  terminal  symbols  are 
labeled  with  the  terminal  symbol.  As  soon  as  a basic  substate  of  the 
original  lookahead  state  has  a unique  terminal  symbol  string  attached 
to  it,  it  has  been  separated  frora  the  lookahead  expansion  and  is  removed 
from  further  consideration.  The  expansion  is  done  using  the  DPDA  infor- 
mation only. 

The  lookahead  expansion  using  the  graph  representation  for  the 
lookahead  states  L3  and  -.11  of  the  example  grammar  is  shown  in  Figure  Al. 
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We  see  that  lookahead  state  L3  contains  basic  substates  R3  and  A2 
(this  corresponds  to  CFSM  state  S3).  R3  contains  only  a single  read 
transition  on  * to  R9-  A2  has  two  top  state  transitions  in  its  asso- 
ciated top  state  vector  T2;  these  are  transitions  to  R2  and  RIO.  R2 
contains  two  transitions:  a transition  on  $ to  A1  and  a transition 

on  to  R8.  Similarly,  RIO  contains  two  transitions:  a transition  on 

+ to  r8  and  u transition  on  ) to  A?.  Now  the  basic  substates  R3  and  A2 
have  unique  strings  and  the  expansion  for  lookahead  state  L3  has  been 
completed.  The  expansion  for  Lll  is  very  similar. 

We  can  now  enter  the  lookahead  state  information  into  the  parsing 
tables.  We  can  perform  some  optimization  by  noting  that  one  of  the 
basic  substates  can  be  assigned  as  a default  substate.  Then  we  only 
need  test  explicitly  for  strings  for  the  non-default  substates,  and, 
if  they  all  fail,  we  enter  the  default  substate.  This  approach  does 
not  compromise  the  error  detecting  ability  of  the  parser  since  during 
lookahead  we  are  only  inspecting  symbols,  not  reading  them.  The  symbols 
for  both  default  and  non-default  states  will  be  read  in  subsequent  read 
states  at  which  time  error  detection  occiirs. 

The  lookahead  states  can  be  tabulated  by  listing  the  state  identity, 
the  lookahead  string,  and  the  destination  state  to  be  taken  if  the  string 
is  found.  The  word  OTHER  is  used  to  denote  the  default  condition.  For 
the  example  grammar : 

L3  * R3 

OTHER  A2 

Lll  * Rll 

OTHER  A3 

This  completes  the  discussion  of  the  derivation  of  the  LR(k)  parsing 
tables  under  the  condition  that  no  error  recovery  or  semantic  actions  are 
permitted  within  a production.  The  extension  to  these  situations  will  be 
covered  later. 


12U 


1*.  LR(k)  PARSKB  OPERATION 

The  LR(k)  parser  operates  as  a finite  state  deterministic  pushdown 
automaton,  reading  symbols  provided  by  the  lexical  analyzer,  pushing 
read  states  onto  the  stack,  and  popping  states  off  the  state  when  pro- 
ductions are  applied.  Lexical  symbols  are  consumed  only  by  read  states; 

lookahead  states  examine  lexical  symbols  but  do  not  consume  them  they 

are  consumed  by  subsequent  read  states. 

The  parser  begins  with  the  stack  empty  and  automatically  transitions 
to  an  initial  state.  In  the  absence  of  error  recovery  and  semantic  actions 
internal  to  the  productions  the  initial  state  will  always  be  the  read  state 
Rl.  Thus,  when  the  initial  trainsition  to  R1  is  made,  the  parser  will  push 
R1  onto  the  stack.  Since  a read  state  has  been  entered,  the  lexical  analyzer 
will  be  called  to  deliver  the  first  lexical  symbol.  This  symbol  is  compared 
against  terminal  symbols  in  the  parsing  table  for  the  read  state.  If  com- 
parison is  found  a traiisition  is  made  to  the  specified  destination  state. 

If  no  comparison  is  found,  the  parser  signals  a syntax  error;  if  error 
recovery  capability  has  been  included  in  the  grammar,  the  error  recovery 
mechanism  will  be  initiated. 

Subsequent  states  may  be  read,  apply,  or  lookahead  states.  Whenever 
an  apply  state  is  entered,  the  stack  is  popped,  the  stack  top  state  is 
examined,  and  a transition  is  made  to  a destination  state  specified  by  the 
top  state.  When  a lookahead  state  is  entered  the  parser  requests  symbols 
from  the  lexical  analyzer  in  a lookahead  mode  and  traverses  the  lookahead 
symbol  strings  stored  in  the  parser  tables , comparing  the  actual  symbols 
against  the  strings  in  the  tables.  When  sufficient  symbols  have  been 
found  to  determine  the  lookahead  destination  state,  the  parser  leaves 
the  look€ihead  mode  and  makes  a transition  to  the  appropriate  state.  The 
symbols  delivered  by  the  lexical  analyzer  in  the  lookahead  mode  will  be 
redelivered  to  the  parser  in  subsequent  read  states,  although  lexical 
analysis  will  not  have  been  repeated  for  them. 
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This  description  of  the  parser  operation  permits  us  to  examine 
the  parse  of  a string  of  lexical  symbols  corresponding  to  the  example 
grammar.  Let  us  use  the  string  (a+b)*c$  where  a,  b,  and  c are  specific 
instances  of  the  identifier  i in  the  grammar.  A step  by  step  narrative 
description  of  the  parser  action  will  be  given. 

1.  Enter  state  Rl,  push  R1  on  stack,  read  (;  a match  is  found  with  a 
transition  to  R6. 

2.  Enter  r6,  push  R6  on  stack,  read  a;  a match  is  found  (a  is  an 
identifier  i)  with  a transition  to  A6. 

3.  Apply  production  6 by  popping  0 entries  off  stack.  Use  top  state 
vector  T6.  Top  state  on  stack  is  now  R6  so  make  a transition  to  A**. 

L.  App^y  production  by  popping  0 entries  off  stack.  Use  top  state 
vector  Ti*.  Top  state  in  stack  is  now  R6  so  make  a transition  to  L3. 

5.  Enter  lookahead  mode  in  state  L3.  Next  symbol  is  + which  belongs  to 
default  string,  so  make  transition  to  A2.  Leave  lookahead  mode. 

6.  Apply  production  2 by  popping  0 entries  off  stack.  Use  top  state 
vector  T2.  Top  state  on  stack  is  now  R6  so  make  transition  to  RIO. 

7.  Enter  RIO,  push  RIO  on  stack,  read  +;  a match  is  found  with  a transition 
to  R8. 

8.  Enter  R8,  push  R8  on  stack,  read  b;  a match  is  found  with  a transition 
to  A6. 

9.  Apply  production  6 by  popping  0 entries  off  stack.  Use  top  state 
vector  t6.  Top  state  on  stack  is  now  R8  so  make  a transition  to  Ah. 

10.  Apply  production  h by  popping  0 entries  off  stack.  Use  top  state 

vector  TU.  Top  state  on  stack  is  now  R8  so  make  a transition  to  Lll. 

11.  Enter  lookahead  mode  in  state  Lll.  Next  symbol  is  ) which  belongs  to 

default  string,  so  make  a transition  to  A3.  Leave  lookahead  mode. 

12.  Apply  production  3 by  popping  2 entries  off  stack.  Use  top  state 

vector  T2.  Top  state  on  stack  is  now  R6  so  make  a transition  to  RIO. 

13.  Enter  RIO,  push  RIO  on  stack,  read  );  a match  is  found  with  a 

transition  to  A7. 


126 


lU.  Apply  production  7 by  popping  2 entries  off  stack.  Use  top  state 

vector  T6.  Top  state  on  stack  is  now  R1  so  make  a transition  to  Ah. 

15.  Apply  production  U by  popping  0 entries  off  stack.  Use  top  state 
vector  TI4.  Top  state  on  stack  is  now  R1  so  make  a transition  to  L3. 

16.  Enter  lookahead  mode  in  state  L3.  Next  symbol  is  * which  specifies 
a transition  to  R3.  Leave  lookahead  mode. 

17.  Enter  R3,  push  R3  on  stack,  read  a match  is  found  with  a transition 
to  R9. 

18.  Enter  R9,  push  B9  on  stack,  read  c;  a match  is  found  with  a transition 
to  A6. 

19.  Apply  production  6 by  popping  0 entries  off  stack.  Use  top  state 
vector  T6.  Top  state  on  stack  is  now  R9  so  make  a transition  to  A5. 

20.  Apply  production  5 by  popping  2 entries  off  stack.  Use  top  state 
vector  TL.  Top  state  on  stack  is  now  R1  so  make  a transition  to  L3. 

21.  Enter  lookahead  mode  in  state  L3.  Next  symbol  is  $ which  belongs 

to  default  string,  so  make  a transition  to  A2.  Leave  lookahead  mode. 

22.  Apply  production  2 by  popping  0 entries  off  stack.  Use  top  state 
vector  T2.  Top  state  on  stack  is  now  R1  so  make  a transition  to  R2. 

23.  Enter  R2,  push  R2  on  stack,  read  $;  a match  is  found  with  a transit 'on 
to  Al. 

2h,  Apply  production  1 by  popping  1 entry  off  stack.  Use  top  state 
vector  Tl.  Top  state  on  stack  is  now  R1  so  make  a transition  to 
state  0. 

25.  State  0 is  the  final  state  of  the  parser  indicating  a successful 
completion  of  the  parse. 

The  parse  tree  which  corresponds  to  parsing  of  the  above  example 

is  shown  in  Figure  A2. 
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5.  INCLUSION  OF  EMBEDDED  ACTIONS  IN  PRODUCTIONS 


The  previous  discussion  has  been  concerned  with  the  construction  of 
LR(k)  parsers  in  which  no  arbitrary  actions  have  been  permitted  inside 
of  the  productions.  Such  a parser  permits  coupling  with  semantic  routines 
and  syntax  directed  translations  after  a production  has  been  completed  but 
prior  to  popping  the  stack.  We  now  extend  the  parser  to  include  arbitrary 
actions  at  any  point  during  the  formation  of  a production,  including 
actions  which  occur  before  the  first  term  of  the  production  is  processed. 

There  are  two  important  applications  for  such  arbitrary  actions. 

First,  it  permits  the  user  to  specify  error  recovery  information  at  any 
point  during  the  parse.  Second,  the  user  has  the  capability  of  calling 
semantic  routines  at  any  point  in  the  parse,  not  Just  at  the  end  of  a 
production. 

We  will  discuss  the  extension  of  the  parser  in  terms  of  action 
commands  which  may  be  embedded  in  the  grammar.  Action  commands,  repre- 
sented by  action  symbols,  will  be  handled  in  a manner  similar  to  terminal 
symbols  with  some  important  differences.  They  will  generate  action  states 
as  opposed  to  read  states.  They  do  not  enter  into  the  lookahead  process. 

On  the  other  hand,  they  tend  to  create  additional  inadequate  states  in  the 
CFSM,  and  lookahead  strings  considerably  longer  than  the  k symbols  dictated 
by  the  underlying  LR(k)  grammar  can  arise  in  certain  situations. 

The  action  commands  provide  a means  of  interacting  arbitrarily  with 
the  parsing  operation.  As  such  it  is  irrelevant  whether  they  are  used 
for  semantic  routine  coupling  purposes  or  for  error  recovery;  the 
principal  concern  is  a technique  for  coupling  with  the  grammar  of  interest. 

We  start  with  a numbered  set  of  productions,  which  may  include  action 
commands,  with  the  production  defining  the  grammar  goal  symbol  occurring 
first.  We  now  proceed  to  build  a CFSM  in  the  same  manner  as  before  by 
developing  basic  states  emd  expanding  these  basic  states  whenever  a non- 
terminal occurs.  The  action  symbols,  terminal  symbols,  and  the  # symbol 
do  not  lead  to  additional  items  in  the  state  expansion. 


We  then  classify  the  CFSM  states  as  read  states,  action  states, 
apply  states,  and  inadequate  states.  The  definitions  for  read  and 
apply  states  are  the  same  as  before.  An  action  state  contains  only 
a single  action  symbol.  All  other  states  are  inadequate  states.  Thus 
we  see  that  an  inadequate  state  can  represent  any  combination  of  terminal 
symbols,  action  symbols,  and  H symbols. 

We  now  construct  a DPDA  in  a manner  similar  to  that  used  before.  The 
terminal  read  transitions  of  CFSM  read  and  inadequate  states  generate  DPDA 
read  states.  Each  # symbol  in  the  CFSM  generates  an  apply  state  in  the 
DPDA.  Each  action  symbol  in  the  CFSM  action  and  inadequate  states  generates 
a DPDA  action  state.  The  CFSM  inadequate  states  generate  DPDA  lookahead 
states. 

The  top  state  vector  now  contains  the  initial  read  or  action  state 
identities  for  each  production.  This  extension  to  actions  states  is 
essential  since  a production  may  specify  an  action  command  before  the 
first  grammar  term.  In  order  to  keep  the  stack  from  containing  super- 
fluous information  during  parsing  only  the  read  states  and  any  action 
state  which  is  the  initial  term  in  a production  are  pushed  onto  the 
stack.  Thus,  when  the  production  is  applied,  the  usual  n - 1 grammar 
symbols  are  popped  if  the  production  begins  with  a grammar  symbol;  one 
additional  symbol  is  popped  if  the  production  begins  with  an  action 
symbol . 

The  lookahead  expansion  differs  considerably  from  that  used  when 
action  symbols  are  not  present.  Whereas  before  lookahead  was  necessary 
only  to  decide  whether  a production  should  be  applied  or  another  terminal 
symbol  should  be  read,  (i.e.,  lookahead  was  associated  only  with  the  end 
of  a production),  now  we  must  decide  whether  to  perform  an  action,  apply 
a production,  or  read  a terminal  symbol  (i.e.,  lookahead  may  be  associated 
with  any  point  in  a production). 
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The  situation  can  be  illustrated  by  the  following  example. 

Suppose  that  we  have  the  following  two  productions  in  the  grammar: 

A = w X V y 
A = w Y V z 

where  A is  a nonteminal , X and  Y specify  two  different  actions,  and 
w,  V,  y,  and  z are  strings  of  terminal  and  nonterminal  symbols.  Upon 
encountering  the  symbols  X or  Y we  have  no  knowledge  as  to  which  production 
we  are  in,  and  thus  have  no  basis  for  choosing  X or  Y to  be  executed.  Thus, 
we  must  do  a lookahead  noting  whether  we  ultimately  encounter  the  string  y 
or  z in  order  to  make  the  decision.  Since  the  string  of  symbols  v may  be 
arbitrarily  long  we  note  that  the  amount  of  lookahead  required  may  be  quite 
large  compared  to  that  demanded  by  the  intrinsic  grammar. 

In  performing  the  lookahead  expansion  we  separate  the  lookahead  state 
into  its  basic  substates;  these  may  be  read  states,  action  states,  and 
apply  states.  We  then  expand  each  basic  substate  until  a unique  symbol 
string  has  been  constructed  for  each  substate,  thus  resolving  the  lookahead 
problem.  In  this  expansion  any  action  state  encountered  automatically 
transitions  to  its  destination  state. 

Expansion  of  an  apply  state  into  all  of  its  potential  top  state 
vector  destinations  can  lead  to  serious  problems  however.  The  problem 
can  be  illustrated  with  the  following  grammar: 

B = a X C d 
B = a C f 
C = g 

where  A,  B,  and  C are  nonterminals,  X is  an  action,  and  a,  d,  f,  and  g 
are  terminals.  We  find  upon  doing  the  reduction  for  C that  if  we  use 
all  top  state  destinations  that  we  have  no  capability  of  resolving  the 
lookahead  ambiguity,  i.e.,  the  choice  of  whether  to  read  g or  do  action  X 
cannot  be  resolved  by  a finite  lookahead.  But  clearly  such  an  impasse 
does  not  really  exist.  What  is  nee'^ed  is  to  know  which  production  B 
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was  being  used  in  the  lookahead  expansion  so  that  only  the  top  state 
associated  with  that  production  is  used  when  the  reduction  to  C is 
completed.  This  can  be  retained  for  each  component  of  the  original 
lookahead  state  by  using  a pushdown  stack  which  stores  that  information 
as  each  read  state  is  encountered.  As  a reduction  is  made,  the  appro- 
priate stack  is  popped  and  a top  state  transition  is  made  as  though 
normal  parsing  were  occurring.  But  notice  that  the  stack  may  be 
exhausted  before  the  lookahead  is  resolved.  This  means  that  the  local 
context  of  the  lookahead  has  been  exhausted  and  that  we  have  moved  out 
into  additional  productions  which  could  have  called  the  production 
from  which  the  lookahead  situation  was  initiated.  In  this  case  we  must 
now  use  all  top  states  since  we  have  no  way  of  knowing  which  top  state 
is  the  correct  one.  This  is  equivalent  to  the  situation  in  resolving 
lookaheads  for  grammars  which  do  not  contain  action  specification. 

6.  ERROR  RECOVERY 

The  error  recovery  mechanism  depends  upon  the  specification  within 
the  grammar  of  error  recovery  initiators  and  error  recovery  points.  The 
initiators  and  recovery  points  always  occur  in  pairs  with  the  initiator 
preceding  the  recovery  point  in  the  grammar.  Also,  the  members  of  a 
pair  must  occur  in  the  same  production.  Pairs  may  be  nested  to  any 
depth,  providing  the  capability  for  hierarchical  error  recovery. 

The  error  recovery  initiator  specifies  a terminal  symbol  which  the 
parser  will  search  for  in  the  input  string  in  the  event  of  an  error.  A 
recovery  will  be  attempted  at  the  point  where  the  recovery  symbol  is 
located  in  the  input  string.  However,  it  is  also  necessary  for  the 
parser  to  locate  itself  both  in  the  parsing  tables  and  in  the  DPDA  stack 
so  that  it  can  resume  the  parse  at  the  designated  point  in  the  input 
string  as  though  nothing  had  gone  wrong.  The  information  necessary  to 
adjust  the  parser  is  specified  by  the  error  recovery  point  in  the 
production. 
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An  error  recovery  stack  is  maintained  in  addition  to  the  normal 
DPDA  stack  used  by  the  parser.  Under  normal  error  free  parsing,  any 
error  recovery  initator  action  pushes  its  associated  error  recovery 
symbol  onto  the  error  recovery  stack.  When  the  corresponding  error 
recovery  point  action  is  encountered,  the  appropriate  error  recovery 
symbol  is  popped  from  the  stack  (it  will  always  be  on  the  top  of  the 
stack  in  error  free  operation  because  of  the  nested  pairing  requirement 
for  initiators  and  recovery  points ) . Thus  the  recovery  stack  at  any 
point  in  the  parse  represents  a hierarchical  error  recovery  system,  with 
the  top  of  the  stack  representing  the  most  local  error  recovery  capability 
and  the  bottom  of  the  stack  the  most  global  capability. 

When  an  error  occurs  the  parser  reports  the  error  and  immediately 
suspends  parsing  action.  The  lexical  analyzer  is  then  repetitively  called 
using  a standard  scanner  until  a lexical  symbol  is  delivered  which  matches 
an  error  recovery  symbol  in  the  error  recovery  stack.  At  this  point  error 
recovery  is  attempted.  The  DPDA  stack  and  the  parser  table  pointers  are 
adjusted  and  parsing  is  resumed  after  popping  all  error  recovery  entries 
down  to  and  including  the  matching  entry  in  the  recovery  stack.  In  the 
event  that  recovery  was  incorrect  another  error  will  soon  be  reported  and 
the  recovery  will  be  attempted  again. 

Since  the  DPDA  stack  position  is  known  at  the  time  the  error  recovery 
initiator  action  occurs,  it  is  trivial  to  calculate  the  correct  stack 
fxjsition  at  the  corresponding  error  recovery  point  since  both  initiator 
and  recovery  point  actions  are  in  the  same  production  with  a fixed  number 
of  grammar  symbols  separating  them.  The  location  in  the  parsing  tables 
for  the  error  recovery  point  is  also  well  known  since  it  corresponds  to 
a particular  action  state  which  is  coupled  to  the  initiator  action  state. 
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APPENDIX  B 


THE  LR(k)  PARSER  GENERATOR 

The  LR(k)  parser  consists  of  a set  of  subroutines  which  are  programmed 
by  parsing  tables  to  permit  recognition  of  sentences  in  a particular  language. 
The  generation  of  the  parsing  tables  is  quite  complex  and  tedious;  thus  it 
is  desirable  to  have  the  parser  table  generation  process  automated.  The 
LR(k)  Parser  Generator  performs  the  function  of  automatically  generating 
the  LR(k)  tables.  The  tables  also  include  information  concerning  error 
recovery,  semantic  routine  interfaces,  and  multiple  syntax  directed  trans- 
lations . 

1 . INPUT  SPECIFICATION 

Input  to  the  parser  generator  is  in  the  form  of  card  images.  The 
input  deck  is  divided  into  two  sections.  The  first  section  describes  the 
lexical  symbols,  their  lexical  codes,  and  the  assignment  of  lexical  symbols 
to  scanners.  The  second  section  describes  the  productions  of  the  grammar 
using  a BNF  notation,  along  with  error  recovery  mechanisms,  semantic  routine 
interfaces,  and  syntax  directed  translations.  The  input  is  terminated  with 
an  END  card.  Comment  cards  may  be  inserted  at  any  place  in  the  input  deck. 

The  input  deck  grammar  is  given  in  Appendix  J. 

a.  Grammar  Symbols 

The  grammar  is  specified  in  terms  of  lexical  symbols  (or  terminal 
symbols)  and  nonterminal  symbols.  The  user  may  compose  alphameric  identi- 
fiers to  represent  these  symbols  for  purposes  of  describing  the  grammar. 

Each  identifier  may  be  of  arbitrary  length,  must  begin  with  a letter,  and 
contain  only  letters  and  digits. 

The  user  may  also  define  any  arbitrary  string  of  symbols  (including 
blanks)  to  represent  a lexical  symbol.  The  arbitrary  symbol  string  is 
delimited  by  the  symbol  $ at  the  beginning  and  end  of  the  character  string. 

If  the  character  $ is  required  in  the  character  string,  it  is  prefixed 
with  another  $ character  which  acts  as  an  escape  symbol . 
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The  delimiting  $ characters  are  merely  used  as  endmarkers  in 
identifying  the  desired  character  string  and  are  not  retained  when  the 
character  string  is  internally  stored.  Note  that  $ABCDEF$  is  identical 
to  ABCDEF  because  of  this  fact. 

Sequences  of  $ delimited  character  strings  must  be  separated  by  a 
blank  to  prevent  the  trailing  $ of  one  from  becoming  an  escape  character 
for  the  leading  $ of  the  next  string.  For  example,  the  sequence  $+$  $*$ 
must  not  be  written  as  $+$$*$;  the  last  form  represents  the  character 
string  +$* . 

b.  Lexical  Interface  Description 

The  parser  obtains  lexical  symbols  from  the  lexical  analyzer. 

The  lexical  analyzer  may  contain  from  1 to  15  scanners,  and  a particular 
symbol  may  be  obtainable  from  more  than  one  scanner.  Since  the  lexical 
analyzer  and  parser  are  separate  software  entities  with  tables  which  are 
independently  generated,  it  is  necessary  for  the  Parser  Generator  to 
know  from  which  scanners  a particular  lexical  symbol  may  be  obtained,  and 
what  lexical  code  is  assigned  to  the  lexical  symbol  by  the  lexical  analyzer 
In  this  way  the  Parser  Generator  is  able  to  designate  a particular  scanner 
to  be  used  at  a given  point  in  the  parse , with  assurance  that  all  the 
possible  legal  symbols  which  can  occur  at  that  point  can  be  delivered 
by  the  designated  scanner.  By  knowing  the  lexical  code  assignment  for 
the  lexical  symbols  the  parser  is  able  to  differentiate  between  the 
various  choices  and  continue  to  the  next  state  in  the  parsing  algorithm. 

The  lexical  interface  description  is  designated  on  a scanner  by 
scanner  basis,  using  a sequence  of  scanner  blocks,  one  for  each  scanner 
of  interest.  Each  scanner  block  is  introduced  by  a card  with  the  format: 

/LEXICAL  n 

where  n = the  scanner  number.  This  is  then  followed  by  one  or  more  cards 
which  designate  the  lexiceLl  symbols  which  are  obtainable  from  the  desig- 
nated scemner.  Each  lexicetl  symbol  card  has  the  format 

lexsymbol  lexcode 
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where  lexsymbol  is  the  identifier  chosen  to  represent  the  lexical  symbol, 
and  lexcode  is  the  numerical  lexical  code  assigned  to  that  symbol. 

c.  Grammar  Specification 

The  grammar  specification  lists  all  of  the  productions  using  BNF 
notation  written  in  terras  of  the  identifiers  chosen  to  represent  the  non- 
terminals and  lexical  symbols.  The  grammar  specification  block  is  intro- 
duced by  the  card 

/BNF 

This  card  is  immediately  followed  by  the  grammar  productions,  where  the 
first  production  defines  the  grammar  goal  symbol.  Each  production  is 
written  in  the  form 

nonterm  = productiondef 

where  nonterm  is  a nonterminal,  and  productiondef  is  a sequence  of  non- 
terminal and  lexical  symbols  which  define  the  production.  The  nonterminal 
on  the  left  hand  side  is  called  the  production  goal  symbol.  There  may  be 
as  many  productions  with  the  same  production  goal  symbol  as  desired;  this 
is  true  even  when  the  production  goal  symbol  is  also  the  grammar  goal 
symbol.  Productions  may  also  be  left  recursive  (the  production  goal 
symbol  appears  as  the  first  symbol  on  the  right  hand  side)  or  right 
recursive  (the  production  goal  symbol  appears  as  the  last  symbol  on  the 
right  hand  side).  Right  recursive  productions  will  be  flagged  with  a 
warning  message  by  the  Parser  Generator  since  such  productions  can  lead 
to  stack  overflow  during  actual  parsing. 

An  example  of  grammar  specification  for  simple  mathematical  expressions 
is : 

S = E 
E = T 

E = E $+$  T 
T = F 

T = T $*$  F 
F = I 

F = $($  E $)$ 

where  S is  the  grammar  goal  symbol;  S,  E,  T,  and  F are  nonterminals;  and 
$♦$,  $*$,  I,  $($,  and  $)$  are  lexical  symbols. 
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d.  Error  Recovery  Specification 

The  LR(k)  parser  is  completely  deterministic  and  will  announce 
syntax  errors  immediately.  However,  the  recovery  ^rom  a syntax  error 
can  be  quite  difficult.  Although  it  is  possible  to  devise  automatic 
methods  for  recovering  from  errors  (which  may  or  may  not  result  in 
recovery,  depending  upon  the  subtlety  of  the  error),  it  was  decided 
that  the  error  recovery  information  should  be  incorporated  by  the  user 
directly  into  the  grammar  description  itself.  This  technique  ensures 
eventual  error  recovery  and  usually  recovers  quickly  with  high  reliability 
whenever  the  offending  section  of  text  has  been  passed  over. 

The  error  recovery  mechanism  consists  of  two  special  symbols,  one 
to  specify  an  error  recovery  symbol,  the  other  to  specify  the  recovery 
point  in  the  grammar.  The  error  recovery  symbol  designator  specifies 
the  lexical  symbol  which  will  be  sought  in  the  input  text  should  an  error 
occur.  The  recovery  point  symbol  specifies  the  point  in  the  grammar  at 
which  parsing  will  attempt  to  resume  following  the  discovery  of  an  error. 

The  error  recovery  problem  involves  the  simultaneous  handling  of  two 
problems.  First,  since  the  input  text  contains  errors,  it  is  necessary  to 
skip  over  a portion  of  the  text,  starting  at  the  point,  where  the  error  was 
discovered,  to  a point  where  valid  text  can  again  be  recognized.  At  the 
same  time,  the  parser  must  adjust  its  stack  contents  and  table  pointers 
so  that  it  is  able  to  resume  parsing  as  though  nothing  had  gone  wrong. 

The  error  recovery  symbol  designator  specifies  the  symbol  which  must 
be  located  in  the  input  text  should  an  error  be  encountered.  This  searching 
is  done  using  scanner  1,  so  that  it  is  imperative  that  scanner  1 be  capable 
of  delivering  the  lexical  symbol  which  is  being  specified  for  error  recovery. 
The  recovery  point  designator  indicates  the  point  in  the  grammar  at  which 
error  recovery  will  have  occurred,  corresponding  to  the  successful  acquisition 
of  the  recovery  symbol  in  the  text,  and  thus  permits  the  parser  to  adjust 
its  stack  and  table  pointers  correspondingly. 
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From  the  above  description  it  can  be  seen  that  the  two  special 
symbols  associated  with  error  recovery  occur  in  pairs,  like  left  and 
right  parentheses.  Both  members  of  a pair  must  occur  in  the  same  pro- 
duction. Pairs  may  be  nested  in  the  same  way  that  parentheses  may  be 
nested.  Thus  it  is  possible  to  define  a hierarchy  of  active  error 
recovery  specifications.  The  error  recovery  mechanism  attempts  to 
recover  using  the  innermost  error  recovery  pair;  failing  that,  it  will 
use  the  next  innermost  pair,  and  so  on.  Thus  it  can  be  seen  that  if  the 
error  recovery  specification  is  well  chosen  that  recovery  from  even  badly 
garbled  text  can  be  effected. 

The  error  recovery  symbol  is  always  a lexical  symbol.  It  is  speci- 
fied at  some  point  in  the  production  and  is  enclosed  in  parentheses.  The 
error  recovery  point  is  specified  by  the  special  symbol  * at  the  appropriate 
point  in  the  production.  An  example  of  a production  with  nested  error 
recovery  specification  is 

A = B (LP)  C D (C0W4A)  E * F » G 

Following  recognition  of  symbol  B the  parser  would  set  the  lexical  symbol 
LP  into  the  error  recovery  symbol  list.  Following  the  recognition  of 
symbol  D the  parser  would  set  the  lexical  symbol  COMMA  into  the  error 
recovery  list.  If  an  error  is  encountered  in  trying  to  recognize  C,  D, 
or  F,  error  recovery  will  be  attempted  by  searching  the  input  text  for 
lexical  symbol  LP  and  resuming  parsing  with  symbol  G. 

If  an  error  is  encountered  in  attempting  to  recognize  E,  a search 
will  be  made  ''or  lexical  symbol  CO^WA;  if  found,  parsing  will  continue 
with  symbol  F;  however,  if  COMMA  is  not  found  but  LP  is  found,  then 
parsing  will  continue  with  symbol  G. 

Note  that  the  grammar  is  not  changed  by  the  introduction  of  the 
error  recovery  information,  i.e.,  in  the  above  example  the  grammar  still 
remains 

A = BCDEFG 
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e.  Semantic  Routine  Specification 

At  any  point  in  the  parsing  of  a production  it  may  be  desirable 
to  interrupt  the  parse  and  call  a semantic  routine  for  doing  some  side 
processing.  Normally,  this  is  done  at  the  completion  of  a production. 

Just  before  the  parser  reduces  the  production  to  its  goal  symbol.  The 
semantic  routines  are  assigned  integer  numbers  and  a semantic  routine 
can  be  C8d.led  upon  the  completion  of  a production  by  using  the  following 
specification 

A(56)  = B C D 

where  semantic  routine  56  is  called. 

It  is  also  possible  to  call  a semantic  routine  before  the  end  of  a 
production  is  reached,  or  even  before  the  first  symbol  of  the  production 
is  processed.  In  this  case  the  semantic  routine  number  is  specified  at 
the  point  in  the  production  where  the  routine  is  to  be  called,  with  the 
number  enclosed  in  parentheses  as  before. 

A = B (U5)  C (3)  D 
B = (2U)  F G 

When  a seman'.ic  routine  is  called  before  the  production  end  is 
reached,  an  exter ded  looKeihead  situation  can  result.  This  happens  because 
the  parser  may  be  working  on  several  productions  simultaneously  and  must 
look  ahead  to  see  which  of  the  various  productions  it  really  is  processing 
before  it  can  know  whether  to  call  the  semantic  routine.  Thus,  for  example, 
even  though  the  underlying  grammar  may  be  LR(l)  the  parser  may  have  to 
contend  with  lookahead  equivalent  to  an  LR(5)  grammar,  because  of  additional 
lookahead  imposed  by  either  internal  semantic  routine  coupling  or  error 
recovery  specification. 

f.  Syntax  Directed  Translation  Specification 

One  or  more  syntax  directed  translations  (SDTs)  may  be  specified 
along  with  any  production. 
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In  syntax  directed  translation  each  production  is  represented  by  the 
ordered  set  (U,  x,  y)  where  U is  the  production  goal  symbol,  x is  a string 
of  terminal  and  nonterminal  symbols  representing  the  definition  of  U,  and 
y is  a string  of  terminal  and  nonterminal  symbols  representing  the  trans- 
lation of  X.  Since  U is  equivalent  to  x,  U is  also  equivalent  to  the 
translation  y of  x.  In  BNF  notation  the  ordered  set  is  written  in  the 
form 

U = X,  y 

In  writing  the  string  y we  require  that  all  nonterminals  in  y must  also 
appear  in  x.  The  terminal  symbols  in  y may  be  arbitrary.  Furthermore,  we 
associate  a particular  occurrence  of  a nonterminal  in  y with  a particular 
occurrence  of  that  nonterminal  in  x.  If  the  nonterminals  appear  in  the  same 
order  in  x and  y,  this  association  is  obvious  since  it  is  one-to-one.  For 
example; 

liTERM  = MTERM  $•$  MFACTOR , MTERM  MFACTOR 

Here  we  see  that  the  first  occurrence  of  MTERM  in  x corresponds  to  the  first 
(and  only)  occurrence  of  MTERM  in  y,  the  first  occurrence  of  MFACTOR  in  x 
corresponds  to  the  first  occurrence  of  MFACTOR  in  y,  etc.  Thus,  the  SDT 
consists  of  a mapping  of  nonterminals  in  one  string  to  those  in  another 
string.  There  is  no  mapping  permitted  for  the  terminal  symbols. 

It  is  possible  to  specify  mappings  which  are  not  one-to-one  between 
X and  y.  This  is  done  by  assuming  an  implicit  sequential  numbering  for 
each  kind  of  nonterminal  in  x;  y is  then  written  with  each  nonterminal 
suffixed  with  the  number  of  the  corresponding  x nonterminal  enclosed  in 
parentheses.  For  example: 

A=BFBGCBC,  H C(2)  B(3)  B(l)  H B(3) 

where  A,  B,  and  C are  nonterminals,  and  F,  G,  and  H are  terminals. 

Note  that  particular  nonterminals  may  be  reused  or  omitted  with  this  scheme. 
Thus,  the  first  occurrence  of  C in  y corresponds  to  the  second  occurrence 
of  C in  X,  the  first  occurrence  of  B in  y corresponds  to  the  third  occurrence 
of  B in  X,  etc.  The  terminals  F and  G in  x have  no  relation  to  the  terminal 
H in  y. 
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The  syntax  directed  translation  can  be  generalized  to  permit  several 
syntax  directed  translations  to  proceed  in  parallel  with  the  parsing.  Further- 
more, each  SDT  is  permitted  to  access  information  belonging  to  another  SDT. 

In  multiple  SDT  each  production  is  represented  by  an  ordered  set 
(U,  X,  Tl,  T2,  Tn)  where  U is  the  production  goal  symbol,  x is  a 

string  of  terminal  and  nonterminal  symbols  representing  the  definition  of 
U,  and  Tl , T2,  ...,  Tn  are  translations  of  x.  The  ith  translation  is 
represented  by  the  ordered  pair  (i,  y^ ) where  y is  a string  of  terminal 
and  nonterminal  symbols. 

In  BNF  notation  a multiple  SDT  is  written  in  the  form 

U = X,  1 = y , 2 = y , , n = y 

I e:  n 

In  writing  the  strings  y we  require  that  all  nonterminals  in  y must  appear 
in  X.  Again,  the  terminal  symbols  in  y may  be  arbitrary.  We  associate  a 
particular  occurrence  of  a nonterminal  in  y with  a particular  occurrence  of 
that  nonterminal  in  x;  in  addition,  we  associate  the  semantic  value  of  a 
particular  nonterminal  in  y with  a particular  semantic  value  of  the  non- 
terminal in  X. 

Note  that  each  nonterminal  in  x has  n semantic  values  associated  with 
it,  one  for  each  translation  involved  in  generating  that  nonterminal.  Thus, 
the  string  y for  each  translation  T may  designate  both  the  particular  non- 
terminal occurrence  in  x and  the  particular  semantic  value  attached  to  that 
nonterminal  for  purposes  of  constructing  a particular  translation.  When 
the  reduction  to  U is  made,  the  n translations  will  correspond  to  the  n 
semantic  values  to  be  attached  to  U,  and  thus  the  association  is  maintained. 

We  may  append  an  ordered  pair  (j,l)  to  eacn  nonterminal  in  the  translation 
strings  y,  where  J designates  the  nonterminal  occurrence  in  x and  i designates 
the  semantic  value  of  that  nonterminal  to  be  used  in  constructing  y.  If  the 
nonterminals  are  referenced  in  the  same  order  that  they  appear  in  x,  the  J 
index  may  be  omitted  by  writing  (,i);  if  the  ith  semantic  value  is  used  in 
the  ith  translation,  the  i index  may  be  or.itted  by  writing  (j);  and,  finally, 
if  both  i and  J can  be  omitted  no  ordered  pair  is  required  for  designation. 


An  example  of  a multiple  SDT  is  seen  in  the  following  example,  where 
the  production  rule  represents  reduction  of  the  product  of  a math  expression 
term  and  factor  to  a term,  the  translation  T1  represents  the  Polish  prefix 
notation  corresponding  to  the  product,  and  translation  T2  represents  the 
Polish  prefix  notation  for  the  total  differential  of  the  product: 

MTERM  = MTERM  $*$  MFACTOR,  1 = $»$  MTERM  MFACTOR,  2 = $+**$  MTERM  (l,l) 
MFACT0R(1,2)  MFACTOR(l,l)  MTERM(l,2) 

It  is  possible  to  include  dynamically  generated  strings  as  part  of 
SDT  specifications.  Such  strings  are  created  by  semantic  routine  actions 
and  then  subsequently  incorporated  into  a SDT  operation.  The  dynamic 
string  is  specified  in  the  SDT  by  a term  of  the  form  D.n  where  n is  an 
integer.  For  example: 

NETSTATE  = RUNSOLN  EOLC,  $STATE$  D.l  EOLC 

g.  Comments 

Comments  may  be  inserted  as  desired  in  the  input  deck.  Each 
comment  must  begin  with  the  characters  /COMMENT  followed  by  a space. 

For  example, 

/COMMENT  THIS  IS  A CO^^ENT  CARD 

h.  Deck  Structure 

The  parser  generator  input  deck  begins  with  the  lexical  interface 
specification,  followed  by  the  grammar  specification,  and  concludes  with 
the  card 

/END 

i.  Example  Gramm.ur  Specification 

I 

The  following  example  shows  a complete  Parser  Generator  input  deck 
auid  includes  error  recovery,  semantic  routine  interfaces,  and  multiple 
syntax  directed  translations.  The  underlying  grammar  is  for  simple 
mathematical  expressions.  The  first  translation  is  the  Polish  prefix 


notation  for  the  math  expression,  the  second  translation  is  the  Polish 
prefix  notation  for  the  total  differential  of  the  expression,  assuming 
that  all  lexical  symbols  I represent  variables. 

/COMMENT  MATH  EXPRESSION  GRAMMAR  EXAMPLE 

/COMMENT  SDTl  = POLISH  EXPRESSION,  SPT2  = POLISH  DIFFERENTIAL  EXPRESSION 
/LEXICAL  1 
$+$  k 

$*$  5 
$($  6 
$)$  7 
I 2 

EOLC  10 

/COMMENT  EOLC  IS  END  OF  TEXT  MARKER 
/BNF 

S(2)=(E0LC)  E EOLC  *,  E,  E 
E = T,  T,  T 

E = E $+$  (3)  T,  $+$  E T,  $+$  E T 
T = F,  F,  F 

T = T (3)  F,  $*$  T F,  $+$  $»$  $*$  T(l,l)  F(l,2)  F(l,l)  T(l,2) 

F(U)  = I,  I,  I 

F = (5)  $($  ($)$)  E $)$  E,  E 
/END 


2.  OPERATING  DETAILS 

The  LR(k)  Parser  Generator  is  a CDC  6000  computer  program  which 
normally  operates  in  50000  octal  words  of  core.  Since  the  program 
utilizes  dynamic  storage  allocation  techniques  larger  amounts  of  core 
are  required  for  large  grammars. 

Input  to  the  program  is  through  the  system  file  INPUT  in  the  form 
of  card  images.  Listed  output  appears  on  the  system  file  OUTPUT.  The 
parsing  tables  appear  as  card  images  on  file  TAPE?. 

3.  LR(k)  PARSER  SUBROUTINES 

The  subroutines  which  comprise  the  LR(k)  Parser  are  contained  within 
the  LR(k)  Parser  Generator  software.  The  subroutines  are  LRKPRS,  NXTSYM, 
BDLRK,  RDCELL,  APCELl,  APCEL2,  LACELL,  ERROR,  and  XSHIFT.  The  parsing 
tables  are  contained  in  a block  data  subroutine  BDPARS  which  is  auto- 
matically generated  by  the  LR(k)  Parser  Generator. 
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The  user  must  supply  subroutine  SEMANT  if  semantic  processing  is 
specified.  SEMANT  is  called  whenever  a semantic  routine  is  invoked  by 
the  parser.  The  semantic  routine  number  is  passed  as  an  integer  formal 
parameter  to  SEMANT  through  the  linkage  CALL  SEMANT ( ICODE) . 

The  LR(k)  Parser  is  invoked  by  calling  subroutine  LRKPRS.  Control 
is  not  returned  until  completion  of  the  parse. 
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LEXICAL  DIGRAM  ANALYSIS 

The  lexical  analyzer  is  required  to  recognize  ’’.exical  constructs 
which  are  formed  by  groups  of  characters  in  the  input  text  stream.  The 
rules  for  grouping  may  be  very  complex  and  change  from  scanner  to  scanner 
within  the  lexical  analyzer.  The  lexical  analyzer  cannot  be  specified 
without  a knowledge  of  the  possible  adjacent  occurrences  for  lexical 
constructs  which  are  imposed  by  the  grammar  of  the  language.  Once  the 
adjacent  lexical  constructs  are  known  the  termination  rules  for  each 
construct  can  be  specified. 

An  example  of  a lexical  adjacency  problem  may  be  found  in  FORTRAN. 
Consider  the  character  sequence  D01OI=J....  where  the  dots  represent 
input  characters  not  yet  seen  by  the  lexical  analyzer.  At  this  point  we 
do  not  know  whether  a D0  statement  or  a replacement  statement  is  being 
read.  Yet  the  lexical  analyzer  has  been  asked  by  the  parser  to  provide 
a lexical  symbol  for  the  first  lexical  construct,  which  may  be  either  D0 

or  D01OI.  Another  example  is  provided  by  the  sequence  IF(2.E where 

it  is  not  obvious  whether  the  E is  the  start  of  an  exponent  or  of  the 
.EQ.  Boolean  relational  operator. 

Lexical  digram  analysis  permits  the  identification  of  all  permissible 
pairs  of  adjacent  lexical  constructs  in  the  grammar  for  the  purposes  of 
devising  termination  rules  for  the  first  member  of  the  pair  in  the  particular 
scanner  which  recognizes  that  member.  However,  since  the  digrams  arise 
from  the  grammar,  digram  analysis  must  be  performed  as  part  of  the  greimraar 
analysis  by  the  Parser  Generator. 

In  the  above  examples  the  digram  analysis  would  reveal,  among  other 
things , that  the  keyword  D^  may  be  followed  by  an  integer  label , the 
combination  being  Indistinguishable  from  a single  FORTRAN  identifier;  thus 
additional  lexical  lookahead  is  required  to  resolve  the  ambiguity.  Similarly, 
digram  analysis  would  indicate  the  Juxtaposition  of  a number  with  a Boolean 
relational  operator,  from  which  the  problem  of  determining  the  proper  ter- 
mination of  the  lexical  construct  for  a number  becomes  evident. 


Lexical  digrams  are  formed  by  constructing  all  the  possible 
adjacencies  of  terminal  symbols  in  the  grammar.  However,  terminal 
symbols  may  become  adjacent  by  any  of  four  mechanisms  as  viewed  from 
the  grammar  specification.  We  can  formally  calculate  the  digrams  by 
the  use  of  incidence  matrices,  adjacency  matrices,  and  transitive 
closures  of  these  matrices. 

Let  us  assume  a grammar  G given  by  the  U-tuple  G(N,T,P,S)  where 
N = the  set  of  nonterminal  symbols,  T = the  set  of  terminal  symbols, 

P = the  set  of  productions,  and  S = the  grammar  goal  symbol.  We  wish  to 
find  the  set  of  digrams  of  T which  can  occur  in  the  language  generated 
by  the  grammar  G. 

We  define  a matrix  F whose  rows  are  labeled  by  N and  whose  columns 

are  labeled  by  N and  T.  This  matrix  can  be  partitioned  into  and  F„_. 

NN  NT 

An  element  f of  the  matrix  f = (l,  0)  if  there  (does,  does  not)  exist  a 
Ad 

production  in  P of  the  form  A = B Q where  Q may  be  any  arbitrary  string 
of  terminal  and  nonterminal  symbols  including  the  empty  string.  Thus 
the  matrix  F defines  the  first  terminal  or  nonterminal  symbol (s)  which 
begin  a production(s ) which  defines  the  set  of  nonterminals. 

We  next  define  a matrix  X whose  rows  and  columns  are  labeled  by  N 

and  T.  This  matrix  can  be  partitioned  into  ^TN’  ^TT' 

element  x.„  of  the  matrix  X = (l,  O)  if  there  (does,  does  not)  exist  a 
Ad 

production  in  P of  the  form  U = Q A B R where  Q and  R may  be  any  arbitrary 
string  of  terminal  and  nonterminal  symbols  Including  the  empty  string. 

Thus  the  matrix  X defines  the  sets  of  adjacent  symbols  in  the  productions  P. 

We  also  define  a matrix  L whose  rows  are  labeled  by  N and  whose  columns 

are  labeled  by  N and  T.  This  matrix  can  be  partitioned  into  L^^j^  and 

An  element  1 of  the  matrix  L = (l,  O)  if  there  (does,  does  not)  exist  a 
Ad 

production  in  P of  the  form  A = Q B where  Q may  be  any  arbitrary  string 
of  terminal  and  nonterminal  symbols  including  the  empty  string.  Thus  L 
describes  the  last  symbols  N and  T which  may  occur  in  the  productions  P 
which  define  N. 
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The  terminal  digrams  can  arise  from  four  sources,  representing  the 
four  partitions  of  X.  Obviously  the  partition  contributes  terminal 
digrams  due  to  their  explicit  occurrence  in  the  productions. 

The  matrix  X^^^  represents  the  occurrence  of  a terminal  symbol  followed 
by  a nonterminal  symbol.  Since  all  nonterminal  symbols  must  be  expandable 
to  a string  of  terminal  symbols,  we  see  that  there  will  also  be  a digram 
contribution  from  the  X^^j  matrix.  All  that  is  required  is  to  find  the 
first  terminal  symbols  which  occur  as  the  result  of  the  nonterminals. 

! This  information  is  given  by  the  transitive  closure  of  the  matrix 

the  transitive  closure  of  this  matrix  is  denoted  by  Thus,  the  product 

^TN^NT  terminal  digrams  due  to  the  X^^^  matrix  partition. 

The  Xj^  matrix  describes  nonterminals  followed  by  terminals.  Again, 
the  nonterminals  lead  to  strings  of  terminal  symbols.  In  this  case  we 
are  interested  in  the  last  terminal  symbols  in  the  strings  generated  by 
the  nonterminals;  this  is  given  by  the  transitive  closure  However, 

f we  need  the  transpose  of  this  matrix,  or  which  gives  the  nonterminals 

I which  correspond  to  the  last  terminal  symbols  of  the  string.  Then  the 

product  gives  the  terminal  digrams  arising  from  the  matrix 

Finally,  the  matrix  X^^^^  can  make  terminal  digram  contributions. 

Here  we  have  the  adjacency  of  two  nonterminals  in  a production,  both  of 
which  lead  to  terminal  strings.  We  are  interested  in  the  last  terminal 
of  the  string  produced  by  the  row  index  of  X^^^j  and  the  first  terminal  of 
the  string  produced  by  the  column  index  of  Thus,  the  digram  con- 

tribution of  Xjjj^  is  given  by 

The  complete  digram  incidence  matrix  for  terminals,  is  then 

given  by  the  logical  union  of  the  four  terminal  digram  sources : 

°TT  " ^TT  \n^NT  * ^NT  ^ ^NN^NT  ^NT  ^ 

where  the  element  d,„  of  D = (l,  0)  if  the  ordered  terminal  symbol  pair 
Ad  i 1 

A B (does,  does  not)  exist  in  the  language  described  by  the  grammar  (^. 


Ihl 


APPENDIX  D 


THE  LEXICAL  ANALYZER  GENERATOR 

The  lexical  analyzer  consists  of  a set  of  subroutines  which  are 
programmed  by  a set  of  tables  to  permit  recognition  of  specific  lexical 
constructs  associated  with  a particular  language.  The  manual  generation 
of  the  lexical  analyzer  tables  is  not  easily  accomplished;  therefore,  it 
is  useful  to  generate  these  tables  automatically  using  the  Lexical  Analyzer 
Generator. 

1.  INPUT  SPECIFICATION 

Input  to  the  Lexical  Analyzer  Generator  is  in  the  form  of  card  images 
and  consists  of  three  sections.  These  sections  specify  the  lexical  analyzer 
constants,  the  lexical  interface,  and  the  scanner  definitions.  Appendix  L 
describes  the  grammar  for  the  Lexical  Analyzer  Generator  input, 

a.  Constant  Specification 

This  section  of  the  input  assigns  values  to  constants  which  are 
used  by  the  lexical  analyzer  and  describes  the  character  codes  which  are 
to  be  used  as  input  to  the  executing  lexical  analyzer  from  the  character 
generator  subprogram. 

The  maximum  scanner  number  which  will  be  used  by  the  lexical  analyzer 
is  specified  by: 

/MAXSCAN  n 

where  n is  the  maximum  scanner  number.  Scanner  numbers  may  be  assigned  from 
1 to  15. 

Tlie  lexical  tables  may  include  semantic  workspace  for  each  identifier 
in  the  ISTAB  array.  The  user  may  specify  the  size  of  the  workspace  area 
with : 

/WORKSPACE  n 

where  n is  the  number  of  words  to  be  allocated  for  workspace  for  each 
identifier.  The  work.space  area  begins  with  the  second  word  of  each 
identifier  cell  in  ISTAB.  A workspace  length  of  zero  may  be  assigned. 
Appendix  Q discusses  the  ISTAB  array  in  more  detail. 
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Keywords  and  identifiers  are  accessed  by  the  lexical  analyzer  using 
a hash  table  lookup.  The  length  of  the  hash  table  may  be  specified  by: 

/HASHTABLE  n 

where  n is  the  hash  table  length.  The  hash  table  length  must  be  a prime 
number  in  order  for  the  hashing  algorithm  to  work  properly.  The  hash 
table  length  should  exceed  the  maximum  number  of  keywords  and  identifiers 
to  be  stored  by  approximately  10-15%  in  order  to  maintain  reasonably 
efficient  lookup. 

The  keywords  and  identifiers  are  stored  in  the  ISTAB  array  in  a set 
of  cells,  one  cell  for  each  unique  keyword  or  identifier.  Cell  length  is 
variable  and  is  given  by  the  formula: 

N = W + S 1 

where  N is  the  cell  size  in  words,  W is  the  workspace  size  as  specified 
by  the  user,  and  3 is  the  length  of  the  keyword  or  identifier  string  in 
words.  Keywords  and  identifiers  may  be  of  arbitrary  length.  Characters 
are  stored  in  the  string  using  eight  characters  per  word,  and  a special 
terminating  character  is  always  automatically  added  to  the  end  of  the 
string.  Thus,  a string  of  seven  characters  requires  one  word,  whereas 
a string  of  eight  characters  requires  two  words  (the  second  word  contains 
only  the  special  terminating  character).  The  user  may  specify  the  total 
length  of  the  ISTAB  array  which  contains  all  of  the  keyword  and  identifier 
cells  by: 

/IDTABLE  n 

where  n is  the  length  of  the  ISTAB  array  in  words. 

The  lexical  analyzer  reads  characters  delivered  by  the  character 
generator  subprogram  as  input.  Ilie  cha'acters  read  by  the  lexical  analyzer 
are  not  restricted  to  the  standard  keypunch  characters  but  may  be  any 
arbitrary  character  set.  The  characters  are  represented  internally  by 
character  codes,  using  the  positive  nonzero  Integers.  The  maximum 
character  code  value  is  specified  by  the  user  by: 

/CHARCODE  n 

where  n is  the  maximum  character  code  value. 
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Immediately  following  the  specification  of  the  CHARCODE  constant 
the  user  must  specify  the  character  codes  which  are  to  be  used.  The 
character  codes  are  specified  by  listing  the  character  name  followed  by 
the  integer  code  value,  using  one  character  code  specification  per  card. 
Character  names  may  be  represented  by  alphameric  identifiers  of  arbitrary 
length,  provided  that  each  name  begins  with  a letter.  A blank  is  used  to 
separate  the  character  name  from  the  code  value.  For  example: 

A 1 
B 2 
D1  2h 
D2  25 
BLANK  i*5 
EOF  50 

Comments  may  be  included  at  any  point  within  the  constant  section 
except  between  /CHARCODE  and  the  end  of  the  character  code  list.  A 
comment  is  represented  by  the  keyword  /COMMENT  followed  by  a blank  and 
an  arbitrary  comment  text.  For  example: 

/COMMENT  THIS  IS  A COMMENT 

Comments  may  not  be  continued  from  one  card  to  the  next,  although  con- 
secutive comment  cards  may  be  used. 

b.  Interface  Specification 

The  output  of  the  lexical  analyzer  is  a series  of  lexical  codes, 
one  for  each  call  to  the  analyzer,  representing  lexical  constructs  as 
they  are  recognized  from  a normal  left  to  right  scan  of  the  input  sentence. 
The  lexical  codes  are  used  as  input  to  the  parser  which  is  responsible  for 
recognizing  correct  grammatical  constructs  of  the  language  being  read. 

The  lexical  interface  section  specifies  the  names  of  the  lexical 
symbols  and  their  codes.  All  specifications  in  this  section  are  global 
specifications,  i.e.,  they  apply  to  all  scanners  which  are  capable  of 
recognizing  the  lexical  construct  which  do  not  have  local  specifications 
which  override  the  global  specification. 

The  lexical  interface  specification  is  introduced  with  the  card: 
/LEXCODE 
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This  is  followed  by  one  or  more  lexical  symbol  definitions,  one  definition 
per  card.  Each  lexical  symbol  is  defined  by  listing  the  symbol  name 
followed  by  its  lexical  code,  using  a blank  to  separate  the  name  from 
the  code.  Lexical  symbol  names  are  identifiers  of  arbitrary  length  and 
are  formed  using  the  letters  A through  Z,  the  digits  0 through  9,  and 
the  characters  + - ( ) = . / $ * provided  that  first  character  of  the 
identifier  is  not  a digit  or  a / $ * character.  The  lexical  codes  are 
positive  nonzero  integers.  The  same  names  and  codes  may  be  used  for 
lexical  symbols  as  were  used  for  character  code  definition  without 
confusion.  An  example  of  lexical  symbol  definition  is: 

EXPONENT  1*5 
SLASH  36 
D2  109 
•EQ.  53 

The  user  may  also  specify  optional  semantic  information  for  a 
lexical  symbol.  The  semantic  information  is  useful  in  complicated 
situations  where  several  different  keywords  must  have  the  same  lexical 
code,  yet  the  semantic  routines  must  be  able  to  distinguish  certain 
properties  associated  with  the  actual  keywords;  these  properties  can  be 
coded  into  a semantic  bit  field  for  the  lexical  symbol.  The  semantic 
information  may  be  defined  globally  as  described  here  or  locally  under 
an  Individual  scanner,  and  it  may  be  changed  from  scanner  to  scanner 
for  a particular  keyword. 

The  semantic  information  is  microprogrammed,  using  a 29  bit  field 
in  the  first  word  of  the  keyword  or  identifier  cell  in  the  ISTAB  array. 
Microprogramming  is  accomplished  through  a cursor  which  can  be  shifted 
left  in  the  29  bit  field;  initially  it  starts  at  the  right  edge  of  the 
field. 

For  exEimple , suppose  we  define  keyword  MAX  with  lexical  code  35 
and  semantic  value  13.  This  is  done  by: 

MAX  35  13 
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which  places  the  value  13  right  adjusted  in  the  semantic  bit  field. 

We  can  alternately  specify  insertion  of  integers  into  the  semantic 
field  and  shifting  of  the  cursor  left  in  the  field;  each  time  the 
ciirsor  is  shifted  it  redefines  the  right  hand  edge  of  the  semantic 
subfield  for  the  next  Integer.  For  example: 

MAX  35  13  L6  8 L5  2 

This  defines  a semantic  field  containing  three  bytes.  The  rightmost 
byte  is  6 bits  wide  and  contains  13,  the  middle  byte  is  5 bits  wide  and 
contains  8,  and  the  left  byte  fills  the  balance  of  the  semantic  field 
and  contains  2. 

The  user  may  include  keywords  without  any  lexical  or  semantic  codes 
in  the  lexical  interface  section  by  simply  listing  the  keyword.  Such  a 
listing  produces  no  entries  in  the  lexical  analyzer  tables  and  this 
feature  is  available  to  permit  keywords  to  be  globally  listed  when 
their  lexical  codes  are  locally  defined  under  individual  scanners. 

Comments  may  not  appear  in  the  lexical  interface  section. 

c.  Scanner  Specification 

The  lexical  analyzer  is  composed  of  one  or  more  scanners,  each 
of  which  has  different  properties  and  is  capable  of  recognizing  different 
sets  of  keywords  and  other  lexical  constructs.  When  the  parser  calls  the 
lexical  analyzer  it  specifies  a particular  scanner  which  is  to  be  used 
by  the  lexical  analyzer.  This  scanner  must  have  the  capability  of  recog- 
nizing all  of  the  lexical  constructs  which  can  appear  at  that  point  in 
the  parse.  The  scanners  may  be  quite  complex  and  it  is  possible  for  a 
scanner  to  invoke  another  scanner  to  assist  in  the  recognition  of  lexical 
constructs. 

Each  scanner  is  separately  specified,  with  a maximum  limit  of  15 
scanners  permitted.  A scanner  specification  is  Introduced  by: 

/SCANNER  n 

where  n is  the  scanner  number,  an  integer  from  1 through  15. 
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A (scanner  specification  may  be  composeci  of  five  subsections,  which 
specify  tt.e  character  classes,  keywords,  keyword  lengths,  a finite  state 
automaton,  and  an  identifier  code.  These  subsections  may  appear  in  any 
order. 

Comment  cards  may  be  included  in  the  scanner  specification;  however, 
they  may  appear  only  where  a subsection  card  may  appear. 

(l)  Character  Class  Specification 

The  scanner  operates  as  a finite  state  machine  with  one 
character  of  lookahead.  The  scanner  is  composed  of  eight  subscanners, 
any  of  which  may  be  used  to  generate  a symbol.  The  choice  of  subscanner 
is  made  on  the  basis  of  the  first  character  used  in  generating  the  symbol. 
By  means  of  a table  lookup,  indexed  by  the  numerical  code  representing  the 
first  character,  a choice  of  subscanner  is  made.  The  various  subscanners 
have  different  properties,  including  the  ability  to  transfer  control  to 
another  subscanner,  another  scanner,  or  an  external  routine. 

Let  us  define  eight  classes,  one  for  each  subscanner.  We  will 
categorize  the  initial  character  which  is  used  to  generate  a symbol 
as  belonging  to  one  of  the  eight  classes.  Thus,  when  the  initial 
character  is  read,  it  automatically  initiates  the  action  of  one  of 
the  eight  subscanners. 

All  characters  which  cannot  be  valid  initial  characters  for  generating 
a symbol  are  assigned  to  Class  1.  When  a Class  1 character  is  encountered 
as  the  initial  character,  a symbol  code  value  = 0 is  passed  to  the  parser. 
This  code  value  indicates  an  illegal  symbol  and  the  parser  announces  an 
error  in  the  input  sentence. 

All  characters  which  ceui  be  used  as  the  initial  character  in  forming 
keywords  or  identifiers  are  assigned  to  one  of  Classes  2,  3,  and  U.  The 
particular  class  which  is  chosen  depends  upon  the  requirements  for  recog- 
nizing keywords  and/or  identifiers. 
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The  subscanner  initiated  by  a Class  ; character  attempts  to  construct 
the  longest  permissib''e  keyword,  usin»/  s|:>eci  flcally  desi^rnated  keyword 
lengths.  If  the  keyword  is  not  identified,  the  subscanner  then  forms  the 
longest  possible  identifier  using  the  subscanner  for  Class  h.  In  building 
keywords,  the  Class  2 subscanner  consults  a second  table  which  specifies 
whether  a particular  character  can  appear  as  a valid  character  within  the 
main  body  of  the  keyword  or  identifier.  If  a non-keyword/identifier 
character  is  encountered,  construction  of  the  keyword/identifier  is 
terminated;  any  keyword  recognized  up  to  that  point  is  delivered  to  the 
parser,  otherwise,  an  identifier  is  delivered.  The  Class  2 subscanner 
is  useful  for  those  situations  i-n  which  keywords  appear  buried  in  the 
midst  of  other  non-keyword  constructs  which  use  the  same  characters  as 
the  keywords.  An  example  from  FORTRAN  is  the  string  DATAItJ  in  which 
DATA  could  be  a keyword  and  IN  an  identifier  for  DATA  statements,  but 
DATAIN  is  an  identifier  for  replacement  statements. 

The  subscanner  initiated  by  a Class  3 character  is  very  similar  to 
the  Class  2 subscanner.  It  also  attempts  to  recognize  a kevword.  However, 
the  keyword  is  of  unspecified  length  and  is  terminated  only  by  encountering 
a non-keyword/identifier  charac-er.  If  upon  termination  the  construct  does 
not  correspond  to  a keyword,  the  subscanner  delivers  it  as  an  Identifier  as 
before . 

'fhe  subscanner  initiated  by  a Class  ^4  character  is  identical  to  the 
Class  3 subscanner  except  that  it  does  not  look  for  keywords  at  all;  it 
always  treats  the  construct  as  an  identifier,  even  though  it  may  also 
be  a keyword. 

The  subscanner  initiated  by  a Class  5 character  is  a finite  state 
automaton  (FSA)  which  may 'be  programmed  to  meet  a variety  of  needs.  The 
FSA  subscanner  is  an  extremely  powerful  and  flexible  component  of  the 
lexical  analyzer.  It  can  handle  many  difficult  lookahead  situations 
encountered  in  symbol  generation.  The  FSA  is  discussed  later  in  this 
appendix. 


Any  cliaracter  which  is  to  be  completely  ignored  by  the  lexical 
analyzer  (such  as  the  blank  in  FORTRAN)  is  categorized  as  a Class  6 
character.  The  scanner  immediately  reads  the  succeeding  character  and 
proceeds  with  its  normal  action.  Class  6 characters  encountered  by  the 
Class  2,  3,  and  1*  subscanners  are  also  ignored. 

Any  character  which  terminates  an  identifier  or  keyword  but  is 
otherwise  ignored  is  a Class  7 character.  An  example  is  the  blank  in 
NET-2  which  acts  as  a separator  for  keywords  and  identifiers.  The 
scanner  action  is  identical  to  that  for  a Class  6 character,  except 
that  in  the  Class  2,  3,  and  ^4  subscanners  the  keyword  or  identifier 
formation  is  terminated.  Symbol  codes  for  Class  6 and  7 characters 
are  never  delivered  to  the  parser. 

The  subscanner  initiated  by  a Class  8 character  calls  an  external 
subroutine,  selected  by  a designated  numerical  code.  The  external  sub- 
routine is  able  to  provide  any  sort  of  lexical  analysis  which  is 
necessary.  An  example  is  the  concatenation  in  FORTRAN  of  the  various 
real  number  representations  followed  by  the  Boolean  relational  operators. 
It  is  difficult  to  know  whether  the  dot  Is  a period  or  a decimal  point 
and  whether  the  E is  the  introduction  of  the  exponent  or  part  of  the  .EQ. 
Boolean  relational  operator.  The  subroutine  may  set  flags  specifying  a 
restart  of  the  character  string  scan  using  an  alternate  subscanner  or 
scanner . 

In  summary , the  subscanners  may  be  described  by : 

1 Illegal  constructs 

2 Fixed  length  keywords 

3 Arbitrary  length  keywords 

h Identifiers 

5 Finite  State  Automata  processing 

6 Ignore  character,  do  not  terminate  lexical  construct 

7 Ignore  character,  terminate  lexical  construct 

8 External  lexical  processing 
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The  character  class  subsection  is  introduced  by: 

/CLASS 

followed  by  one  or  more  cards  which  assign  characters  to  character 
classes  (and  thence  to  subscanners).  Each  assignment  card  lists  the 
class  number  followed  by  one  or  more  characters  which  are  assigned  to 
that  class.  For  example: 

3 A B C D SLASH  d6 

5 P Q STAR  DOT 

6 BUiNK 

8 EOF  COMMA 

Ail  characters  which  are  permitted  in  keywords  and  identifiers 
following  the  initial  character  are  also  assigned  to  character  class  9- 
Thus,  a scanner  which  can  recognize  the  alphameric  identifiers  permitted 
in  FORTRAN  (including  the  ignored  blank  character)  is  described  as 
follows : 

/CLASS 

Uabcdefghijklmnopqrstuvwxyz 

6 BLANK 

9ABCDEFGHIJKLMN0PQRSTUVWXYZ 

9 DO  D1  D2  D3  DU  D5  D6  D?  D8  D9 

(2)  Keyword  Specification 

The  keyword  subsection  lists  all  lexical  constructs  which  are 
to  be  recognized  as  keywords  by  the  scanner.  If  the  keyword  and  its 
lexical  code  have  been  defined  globally  it  is  only  necessary  to  reference 
the  keyword  here.  However,  if  the  keyword  has  not  been  globally  defined 
or  it  is  desired  to  specify  a local  definition  of  the  keyword,  then  a 
complete  keyword  specification  must  be  made. 

The  keyword  subsection  is  introd\iced  with  the  card: 

/KEYVORDS 
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This  is  followed  by  keyword  specification  or  reference  cards,  one 
for  each  keyword  of  interest.  A keyword  specification  is  made  in 
exactly  the  same  way  as  the  global  specification,  including  semantic 
information  if  desired.  A keyword  reference  only  lists  the  keyword 
itself  without  any  lexical  code  or  semantic  information. 

(3)  Keyword  Length  Specification 

If  the  scanner  is  required  to  recognize  fixed  length  keywords 
it  is  necessary  to  specify  the  fixed  lengths  which  correspond  to  those 
keywords.  This  is  done  with  a single  card  which  begins  with  /KWLKNGTH 
followed  by  a set  of  integers  in  ascending  order  which  specify  the 
keyword  lengths.  Blanks  are  used  as  separators.  For  example,  if  the 
fixed  length  keywords  are  PROGRAM,  FUNCTION,  and  SUBROUTINE,  then  the 
keyword  length  specification  is: 

/KWLENGTH  T 8 10 

The  fixed  length  keywords  are  useful  in  isolating  keywords  which  are 
not  terminated  by  a non-keyword  character.  In  this  way  the  keyword 
FUNCTION  can  be  identified  in  the  text  string  FUNCTIONRANDOM . 

(U)  Finite  State  Automaton  Specification 

The  subscanner  initiated  by  a Class  5 character  is  a finite 
state  automaton  (FSA)  which  may  be  programmed  to  meet  a variety  of 
needs.  The  FSA  consists  of  a set  of  cells  which  are  interconnected  to 
form  a state  diagram.  Each  cell  contains  a symbol  field,  a match  action, 
and  a non-match  action.  The  symbol  field  may  represent  either  a specific 
character  code  or  a class  code.  If  the  input  character  matches  the  symbol 
(in  character  code  or  class  code,  depending  upon  which  type  of  match  is 
indicated)  the  FSA  performs  the  action  specified  by  the  match  action. 

If  the  designated  match  does  not  occur,  the  FSA  performs  the  action 
specified  by  the  non-match  action.  If  a match  is  found,  the  FSA  reads 
a new  character  from  the  character  generator;  if  there  is  no  match,  the 
previous  character  is  retained  for  matching  in  subsequent  FSA  cells. 
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The  FSA  action  may  be  one  of  four  types.  Type  0 is  a transistion 
to  another  FSA  state  (including  the  state  the  FSA  is  currently  in). 

Type  1 exits  the  scanner  and  lexical  analyzer  and  returns  a designated 
symbol  code  to  the  parser.  Type  2 is  a restart  of  the  charcter  string 
scan  using  a designated  class  for  the  first  character;  this  overrides 
the  automatic  class  assignment  for  the  initial  character  and  forces  the 
scanner  to  restart  in  the  designated  class.  Type  3 is  a restart  of  the 
character  string  scan  using  a designated  scanner;  the  subscanner  of  the 
new  scanner  is  selected  in  the  normal  way,  namely,  by  the  class  of  the 
initial  character  using  the  class  table  of  the  new  scanner. 

The  FSA  subsection  is  introduced  by  the  card: 

/FSA 

This  is  followed  by  one  or  more  cards  which  define  the  FSA  states. 

Each  state  of  the  FSA  is  described  by  a card  with  the  format: 

$n,  c,  p,  q 

where  n = an  integer  specifying  the  FSA  state  number,  c = the  character 
field,  p = the  match  action  field,  and  q = the  non-match  action  field. 

The  initial  state  number  is  1. 

The  character  field  c has  one  of  two  forms.  It  specifies  either  the 
character  code  or  class  to  which  the  current  character  is  to  be  compared 
for  a match.  If  the  character  code  is  to  be  compared  then  c contains  the 
character  neime.  If  the  character  class  is  to  be  compared,  then  c contains 
the  class  number. 

The  match  and  non-match  action  fields  may  have  any  of  four  forms. 

If  a transition  to  a new  FSA  state  is  desired,  then  the  field  contains  $n 
where  n is  an  integer  specifying  the  desired  FSA  state  number.  If  exit 
from  the  lexical  analyzer  is  desired,  then  the  field  contains  the  name 
of  the  lexical  symbol  whose  lexical  code  is  to  be  delivered  to  the 
parser.  If  restart  with  a new  subscanner  is  desired,  then  the  field 
contains  an  integer  specifying  the  new  subscanner.  If  restart  with  a 
new  scanner  is  desired,  then  the  field  contains  *s  where  s is  an 
integer  specifying  the  new  scanner  number. 
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(5)  Identifier  Code  Specification 

The  user  must  assign  the  lexical  code  to  be  delivered  by  the 
scanner  when  an  identifier  is  recognized.  This  is  done  by  a single 
card  of  form: 

/IDENTIFIER  n 

where  n is  an  integer  specifying  the  lexical  code  for  identifiers.  If 
the  identifier  code  specification  is  omitted  the  scanner  will  automatically 
deliver  a code  = 0 for  identifiers,  which  is  interpreted  by  the  parser  as 
a syntax  error.  Each  scanner  may  use  a different  identifier  code. 

d.  Deck  Structure 

The  Lexical  Analyzer  Generator  input  deck  begins  with  the  lexical 
analyzer  constants,  followed  by  the  lexical  interface  specification, 
followed  by  the  scanner  specifications , and  concludes  with  the  card; 

/END 

2 . OPERATING  DETAILS 

The  Lexical  Analyzer  Generator  is  a GDC  6000  computer  program  which 
operates  in  50000  octal  words  of  core.  Since  the  program  utilizes 
dynamic  storage  allocation  techniques  larger  amounts  of  core  may  be 
required  for  very  complex  lexical  analyzer  specifications. 

Input  to  the  program  is  through  the  system  file  INPUT  in  the  form 
of  card  images.  Listed  output  appears  on  the  system  file  OUTPUT.  The 
lexical  analyzer  tables  appear  as  card  images  on  file  TAPE?. 

3.  LEXICAL  ANALYZER  SUBROUTINES 

The  subroutines  which  comprise  the  lexical  analyzer  are  contained 
within  the  Lexical  Analyzer  Generator  software.  The  subroutines  are 
LEXAN,  LOOKUP,  ADDCHR , and  XSHIFT.  The  lexical  analyzer  tables  are 
contained  in  a block  data  subroutine  BDLEX  which  is  automatically 
generated  by  the  Lexical  Analyzer  Generator. 
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The  user  must  supply  a subroutine  CHRGEN  which  supplies  characters 
to  the  lexical  analyzer  from  some  external  data  structure.  The  character 
codes  supplied  must  agree  with  the  codes  assigned  internally  in  the 
lexical  analyzer  for  the  characters.  The  character  generator  is  normally 
required  to  have  backtrack  capability  as  required  by  the  Class  2,  5,  and  8 
subscanners . 

The  Class  8 subscanner  requires  the  user  to  supply  subroutine  EXTSCN 
to  accomplish  specialized  external  scanning.  EXTSCN  is  required  to 
provide  both  the  lexical  and  semantic  code  information  to  the  lexical 
analyzer . 

The  lexical  analyzer  is  automatically  invoked  by  the  LR(k)  Parser 
software  through  the  primary  subroutine  LEXAN. 
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APPENDIX  E 

CSL  PARSER  DESCRIPTION 


Tills  appendix  lists  the  BNF’  input  to  the  LR(k)  Parser  Generator 
which  produces  the  LR(k)  parsing  tables  for  CSL.  The  input  listing 
constitutes  a complete  description  of  the  grammar  for  CSL,  including 
identification  of  all  terminal  symbols  and  their  lexical  codes.  The 
grammar  is  LR(2)  and  can  be  represented  by  272  read  states,  199  apply 
states,  and  L8  lookahead  states. 

A listing  of  the  undefined  terminal  symbols  and  their  corresponding 
character  strings  is  given  below: 


Lexical  Symbol 

Character  String 

AND 

.AND. 

SOUNDCARD 

BOUNDS 

COMMENT 

Any  arbitrary  comment  text  ending  with  EOLC  character 

ENDDECK 

END  DECK 

END ENTER 

END  ENTER 

ENDRUN 

END  RUN 

ENDSTATE 

END  STATE 

EOLC 

End  of  logical  card  symbol 

FPNAME 

Any  legal  function  or  procedure  name 

lAA 

Any  identifier  containing  only  alphameric  characters 

IC 

INITIAL  CONDITIONS 

ILA 

Any  identifier  containing  alphameric  characters, 
starting  with  a letter 

ILL 

Any  identifier  containing  only  letters 

INTEGER 

An  unsigned  integer 

KWl 

SENS 

KW2 

N,  NM,  ND,  NP,  NR,  or  NI 

KWU 

I,  V,  P,  IM,  VM,  PM,  ID,  VD,  PD,  IP,  VP,  PP,  IR,  VR,  PR 
II,  VI,  or  PI 

KW5 

AM,  BM,  YM,  ZM,  AD,  BD,  YD,  2D,  AP,  BP,  YP,  ZP,  AR,  BR, 
YR,  ZR,  AI,  BI,  YI,  or  ZI 

l6l 


Lexical  Symbol 


Character  String 


KW5A 

M,  D,  P,  R,  or  I 

KW6 

Any  element  parameter  name 

KWT 

Any  global  name 

KW8 

Any  element  prefix 

KW9 

COMPLEX,  RADIANS,  or  DEGREES 

KWIO 

PRINT 

KWll 

USE  TEXT 

KW12 

A run  control  character 

string 

KW13 

A run  control  character 

string 

KWll* 

A run  control  character 

string 

KW15 

A run  control  character 

string 

kwi6 

A run  control  character 

string 

KWIT 

A nm  control  character 

string 

KW18 

A run  control  character 

string 

KW19 

PLOT 

KW20 

L INLOG,  LOGLIN,  LOGLOG, 

POLAR, 

KW21 

LOG 

KW22 

FINAL 

KW23 

CURVE 

KW2l* 

ENTER  NET,  ENTER  SCEPTRE,  or  El 

KW25 

TABLE 

KW26 

2D 

KW27 

R 

KW28 

PROCEDURE 

KW29 

SUBNET 

KW30 

TEXT 

KW32 

S. 

KW33 

GAUSS,  RECT,  or  TRI 

KW3I* 

OBJ 

KW35 

X 

KWU8 

DATUM 

KWl*9 

PT,  PV,  IV,  or  D 

KW50 

E,  F,  or  Q 

162 


Character  String 


Lexical  Symbol 


LANG 

MATHF 

MCCARD 

NOT 

NUMBER 

OR 

REALNAJ-lr, 

RELOP 

RUN 

RUNOPT 

RUNWC 

STATECARD 

SUBNETEND 

SUBNETNAME 

TEXTLIST 


NOT,  SCEPTRE,  or  CIRCUS 

Any  standard  math  function  such  as  SIN,  COS,  etc. 

RUN  MONTECARLO 

.NOT. 

Any  real  number  representation 

.OR. 

Any  legal  real  variable  name 

.EQ.,  .NE.,  .LT.,  .LE.,  .GT.,  or  .GE. 

RUN 

RUN  OPTIMIZJITION 
RUN  WORST  CASE 
STATE 
END  SUBNET 

Any  legal  s.'bnetwork  name  prefix 

Any  arbitrary  text  with  END  EOLC  as  last  card  image 


The  lexical  analyzer  description  for  the  CSL  grammar  is  given  in 
Appendix  F.  The  complete  CSL  grammar  including  CSL  Translator  directives 
is : 


/COMMENT  GRaMMAM  FOR  FULL  CSL  7/25/75 

/lexical  I 
KW22  92 

Ss$  J7 

STaRGETS  12b 
KW21  91 
S,$  63 
KH27  97 
KW53  103 
$(S  15 
KM20  90 
KK26  9b 
LANG  127 
number  53 
KW23  93 
S)S  lb 
KH35  105 
EOLC  10 
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/LEXICAL  ? 

S(S  lb 
ILA  b2 

S*$  bO 
I-S  h7 

ssss  i}a 

EOLC  10 

5.5  hi 

s/s  14 

S*S  64 
S»*S  65 

SsS  17 

5.5  16 

S)S  16 
AND  60 
OW  59 
NUl  62 
>7ELL)P  61 
/lexical  3 
KW4  74 
S*S  64 

SUHNtlNAMh  131 
KWbO  120 
KIN32  102 
KN49  119 
KEAlnAmE  1J2 
FPNAME  1 Sb 
NUmBEK  53 
CJMMfcNT  129 
KH12  02 
KWl 3 03 
KW14  04 
K*K15  05 
KW16  06 
KWl 7 07 
KW10  86 
KW25  95 
KW7  77 
KN26  90 
SUBNEfENO  112 
Kw34  104 
IC  111 

SOEVICES  125 
MUNHC  110 
SENDS  69 
SENOMUDELS  124 
BOUNOCAHO  113 
KH0  70 
KM19  69 
SHOOtLS  123 


RUNUPr  114 
MCCARO  10« 
ENDOECK  107 
ENOSTATE  lib 
KW24  94 
KWl I 81 
KWiO  100 

endertem  1<?1 

Kw23  9S 
KX<?9  99 
KW48  118 
STATECAHD  115 
RUN  117 
KW 1 0 80 
ENDRUN  109 
/LEXICAL  <i 
KW^3  93 
S/S  14 
S,S  63 
EOLC  10 
S + S 50 
S-S  67 
S(S  15 
MAThE  122 
KHl  7 1 
KN52  102 
KW49  119 
KW7  77 
KW5  75 
KW4  74 
KH22  92 
KW50  120 
KW2  72 

REALNAME  132 
SJBNETNAME  131 
KN8  78 
not  62 

SSSS  134 

KN20  90 
KH9  79 
FPNAMt  135 
number  53 

/lexical  S 

ILL  55 
/lexical  7 
lAA  54 
S/S  14 
KN8  78 

SUBNETNAME  131 
/LEXICAL8 
KHb  76 

/lexical  r 


TEXTLI3T  150 
/LEXICAL  \2 
S(S  15 
KH5A 

If^TEGEW  2 
/HNF 

SsTAHGLXNG  3ECK  DtCKEf^O 
ABUUNDEmTsS, S KN^5 
ABL3UNDE  N I = S,  JKW35 
ABOUNOENTri, J 

ABUUNOF.  S I =5,  S »,*  Kh21 

ABDUNOP NT=S, S KW33  if*  Kw^l 
ABnUNOLlM=NJMBEKS*S 

ABUUNDL IM=ME 

AELEMENI=ELEM  »,S  MUOElIST 

A V[]OE=NaOE 

AN0BE=S/Sn0DE 

anuoeac=s-$nude 

AfJBJsSrS  CU«VEID  $*S  NUMBER 
AUHJsi»S  LUBVEID  if*  NUMHEH  $»$  KW35 

A JP=S+$ 

A JP=S-$ 

AJUTLSTrSSSS  lAA  SSSS 
APAWAM=NuMBEM  $as 
APA«AM=ME 
A»G1 =NUMbPM 
ABGl =UU  rVAM 

a«glist=ila 

AWGLISrsAWGLlSTJ,JlLA 

aswnum=mumhew 

A3HNUM=NUMBE W $*J 

BELEMENT=*=3VaLUES 

BELEME'^f=»(»VALUELIST2$)$ 

BEXPsBTEKM 

bexpsrexp  oh  BTEHM 
BFAcruw=ME  helup  me 

BFACTUH=$(SBEXP»)% 

BFACTUH=NOr  BFACTOH 
BNUDE AC=S/SnOOE  ANOOEAC 
BMUDEAC:3/S  node 

BOUNO=BOUNDCAHD  EOLC  BOUNOLIST  SENDS  EOLC 
BOUNDENTsGHP I 

BCJUNDENr=lNOVAK  S:S  ABUUNOLIH  S,S  ABUUNOLIM  ABOUNDENT 
BUONDLlsr=UOUNOENr  EuLC 
BUUNDLISTsBOUNDLlST  BJUNDENT  EOLC 
BSHNUMLISTsSIS  integeh  Kwai  S)S 
BSnnumlI3TsS(S  integeh  S)S 

btehm=ufactor 

QTEHM=BFERM  and  BFACTOH 
CUHVEsCUHVEID  EULC  NUMLIST 
CURVE IDsKW^3 
OECXsENfHY 
DECK=OECK  entry 
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DECKENDsStNDS  EULC 

deckeno=endoeck  EOLC 

DEPVAW= INDVAW 

depvah=  rokv 

DEPVAkrFDMV 
DEPVAKLSfsDEPVAH 
DEPVAWLST=0EPV AWL3TS, JOEPVAK 
ONODEsKMqnS, SNUOE 
ONUOE=ONOOE»»  SNODE 
OUMNUDELISTsIaa 
DUMNODElIST=DUMNOOELI3TS, SIAA 
ELEMsKnB 

ELEMENTsAELEMENT  BELE^ENT 
ELEHENIsAELEMENT 
ELNAME=ELEM 
EL^^AME  = NEST  J.SELEM 

elval=elname  * 

ElVAl=ElnAmES. $KW6 
E»JTRY  = GHPi 
EN1RY  = INTC()SD 
ENrWY=CU«VE 

ENTMYsKW^a  EUUC  TeXTlIST 

ENTHYsJOEVICES  SfS  lAA  $,S  ILL  $(S  VALUELIST2  S)$  EULC 

ENTWYsSMOdeL*  S»  JlLL$*SNUOELlSr$  = SARGLlST  EL)LC  MnOBLKSENDMflDELSEULC 

EnTRYsmCCARD  ECJLC  mClIST  HUNEND 

ENTRYsKKiO  integer  E(JLC  TEXTLIST 

ENTrYsRUN  EOLC  NSLIST  HUNEND 

ENTRYsHUNUPl  EOLC  QPTLIST  KUNEND 

ENTRY=RUN«C  EOLC  WCLIST  HUNEND 

ENTRYsGRPt? 

ENTRYsGHPI 

FORV=KW^  KHSA  S(S  NODE  S)S 
EDHV=KH4  KNSA  S(S  ELNAME  S)S 
F0RV=KHS  KWSA  S(S  NUDEAC  S)S 
GHPlsKwll  INTEGEW  EOLC 
GWP I =COMMENl 
G»P2=SU8NETHEF  EOLC 

GRP2=SUBNE TcaRD  EOLC  SUBNETLIST  SUBNETEND  EOLC 
C«P2=FPNAmF  &(S  ARGLIST  S)S  SsJ  ME  EULC 
GRP2=TABLE 
GRP2=ELEHENf  EOLC 

G»P2  = Kw?B  $,1  FPNAME  »(S  AHGLiST  S)»  EOLC  TEXTUST 

GRP2=DN0D£  EOLC 

GHP2=REALVAL  »=*  ME  EULC 

GHP  SsHUUNO 

GRP3=HC  FULC 

GRPa=TNTCUNO 

GRPUsPAHAM  EOLC 

I NDVAHsELVAL 

INDVAHsKW/ 

INDVAHsREALVAL 

INDVA«L3tsINDVAR 

INDVAHLSTsINOVARLSTS^SINOVAH 
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I 


lNrcONO=lC  EULC  iNfCONDLlSI  SENDS  EOLC 

INTCUNOLlbTslNTCONDVAN  EOLC 
ISICUNDLISTsINrCUNOLiar  INICONDVAH  EOLC 
I NTCUNDVAH=<Wa  S(S  KWtt  S)S  S=S  ME 
INFCUNDVAHrKhia  i(S  RbALVAL  $)S  S=S  ME 
INfCUNDVARzCMRl 

mcent=cukve 
mcent  = ghp  i 

MCENfrGHPl 
MCEN I =GRP« 

MCENT=MC0UT  EOLC 

MCL  1ST  =MCEN  r 

MCL  1ST  rMtH.ST  MCENT 

MCOUT  = K»<  I OS,  SOUIL3T 

MC0UTSKN19S, SOUTLST 

ME=AUP  MTEHM 

ME=MTERM 

MEsME  AOP  MTEMM 

MFAC  rOHsME AC  fowl 

MFAC fUKsMFAC f ORl  S**S  MFACfURl 

MFACfURl:S(S  ME  S)S 

MFACTURIsmFlINC  S(S  VALUELISTI  S)S 

mfactori=argi 

MFUNCsMATHF 

MFUNCsFPNAME 

MODBLKsMOOENf 

MUDBLKsMUOBLK  muoent 

MOOENT=GRH2 

MOOENf=GRPl 

MODENT=lNfCOND 

HOP=S*S 

MOPsS/S 

MTEPMsMFAC  f QW 

MTEMMsMTEHM  M[)P  MFACTUR 

NESTsSUHNE  TNAME 

NESTsNESTS.SSUBNE  TNAmE 

NUOErl AA 

NOOEsNESTS.SUA 

NUOEsNEST  S.S  KnH  S.S  IAA 

NODE=Km0  S.S  IAA 

NOOEACsNODE  ANOOEAC  bnodeac 

NODEACsNUOE  BNODEAC 

NUOEACsNODE  ANODEAC 

NODEAC=NMDE 

NODEL iSfsANODE 

NODE L I STsNODELISTS-SaNODE 

NSENTsRC  EOLC 

NSENTsGRPI 

NSENTsGRPa 

NSENTsfjUT  EOLC 

NSENTsS*S  SNVAR  EQlC 

NSENr*SMVAH  EOLC 
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NSLlSTsNSENI 
N3LIST=NSL1ST  NStNl 
NJMC  AKD  = NUM‘jt« 

NUMCAKI)  = NUMCARDJ»»NUMBEH 
NUML I ST sNUMC AMD  tJLC 
NUMl1ST=NUMlIST  NUMCAHU  eolc 
UBJ=Kwi«$=S‘lE  AUbJ 
U8J=KWSa  $rl  ME 
UP  TENT  sGMP  5 
UP  TENTsGWPI 
UP  rENTsGMPa 

optent=cumve 

OPTEnTsSTATECAWD  eULC  3TATELIST  STATEfcND 

UPTL ISTsUPTENT 

DPTL ist=uptl I sr  UPTENT 

OUT=KW10  PUUTlST 

UUT=kW19  s,l  KWr»0  PUUTLST 

QUTsKHIV  puutlsi 

UUTLSr=Mt  AHUTlST 

out  LSI: ME 

□UILSTsUUTLST  m£  ADUTLST 

UJTL3T=UUTLST  i,S  ME 

OUTVARs  TDHV 

OUT VARsFORV 

UUTVARsELVAL 

OUTVARsTDVAR 

0UTVARSKN49  STS  TDVAR  S)S 
OUTVAWrKHi?  S(S  TDVAR  S)S 

OUTVAHsKWI  STS  OEPVARLSr  S/S  INDVAHLST  S)S 

PARAHsKN?  SbS 

PARAM=INOVaW»=SaPaRAM 

PUUTlST*S»S  UUTLSI  s»s  s/s  me 

PUUlLSTaS,S  UUTlST  S,S  S/S  ME  AUUTLST 

POUTlST*S»S  OUTlST 

KCsKwtaSsSINTEGER 

RCsKnI 3S:SME 

KCsKNimSsSKmis 

RCsKMtb 

RCsKWlT  STS  «EXP  S)S 
RCsKW I HSzSNUMUER 
HEALVALsRE ALNAME 
REALVALsNESTS.S  healname 
HJMENOsSENOS  EULC 
RUNENOsENDHUN  EULC 
STaTEENDsSENDS  EULC 
STaTEENOsENDSTaTE  EULC 
STATEL I3T=STATENT 
STATELISTsSTATELIST  siatent 
STATENTsGRPl 
STA  TENTsURPa 
STaIFNT=*-'C  EULC 
STaTENTsI  bJ  EULC 
STaTEWTbSMVAK  EULC 
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suune rc Awo=^wa9  s,%  ill  S/S  oumnudelist  $=s  arglisi 

subne tcarg  = kr<'R  s,s  III  s,s  oumnooelist 

SUHNETL1ST=GHR1 

SJBNETL  lsr  = SUIjNE  TLIST  GRPl 

SUbNElL ISTsSUhnE fLlST  GRPa 

SGHNE  TLlSTzGRPa 

SUbne tree sSJBNE INaME  ».S  NODELIST  $=*  SUBNETVAL 
SUBnE tree =SUBNE TNAME  NODELIST 

SJUNETVAL=VALUELISTI 
SJBNE T VAL=S1$$  lAA 

SUBNE TVAL=$JS J lAA  S{$  VALUELI3T^  $)$ 

SWNUML I ST sS, i BSWNUMLIST  ASWNUM 
SWNUML ISTsJ, $ aSWNUH 
3WVaK=PARAM  SWNUMLIST 
SWVAR=PARAM  SHMUMLIST  i,$  KW^2 
s«var=pakam  s,s  Kwaa 
TA»LF=KNab  i.S  KW?b  EDLC  NUMLIST 
TABLE=K«?5  EULC  NUMLIST 

TABLEsKwas  EULC  NUMLIST  NUMBER  S»S  KR?7  tOLC 
f ARGLANG=ST aRGETS  S=S  LANG  EULC 
TORVsKwa  $($  node  S)S 

TORV  = KHtj  S(S  ELNAME  S)S 
rORV=KRSO  $(S  ELNAME  S)$ 

TOVAR=K«7 
TOVARrREAL  VAL 
VALUEL I ST  1 =ME 

valuelisti=valuelistis,$me 

VALUELlSia=KH6S=XME 

VALUELlST2sVALUELlSIP»»SKWf>SsSME 

VALUESSKW9  SIS  ME  S»S  HE  S)S 

VALUES=S(S  HE  %,%  HE  S)S 

VALUES=VALUELISTI 

HCENTsGRPl 

WCENTsGRPa 

MCENTsGRPi 

WCENT=KRlO  S»S  DUTLST  EULC 
WCLISTsrCENT 
WCLISTsHCLIsr  HCENT 
/END 
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APPENDIX  F 


CSL  LEXICAL  ANALYZER  DESCRIPTION 


This  appendix  lists  the  input  to  the  Lexical  Analyzer  Generator  which 
produces  the  lexical  analyzer  tables  to  be  used  with  the  parser  for  CSL 
described  in  Appendix  E.  The  description  of  the  lexical  analyzer  is: 


/COMMfcNT  lexical  analyzer  FUR  CSL  GRAMMAR  7/25/75 

/comment  run  controls  and  must  parameter  symbuls  missing 

/MAXSCAN  12 
/WORKSPACE  I 
/HASHTaBLE  751 
/IDTABLE  2000 
/CHARTaBLE  49 
/CHAKCUDE 
A 1 
B 2 
C 3 

0 4 
E 5 
F 6 
G 7 
H 8 

1 9 
J 1 0 
K 1 I 
L 12 
M 13 
N 1 4 
0 15 
P 16 
Q 17 
R 18 
S 19 
T 20 
U 21 

V 22 
M 23 
X 24 

V 25 
Z 26 
DO  27 
D1  28 
D2  29 
D3  30 

04  31 

05  32 
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06  33 

07  3a 
DB  35 
oa  56 
PLUS  37 
MINUS  58 
STAR  39 
SLASH  ao 
LP  ai 

HP  a? 

DOLLAR  a 5 
Eu  aa 
blank  as 
comma  a6 
DOT  a? 

EULC  aa 
NOCAHO  av 

/lexcude 

FINAL  9a 
LINLOG  90 
LOGLIN  90 
LUCLOG  90 
POLAR  90 
NYQUIST  90 
COMMENT  129 
TEXTLISr  130 
EQ  17 

comma  63 
STAR  6a 
number  53 
EXPONENT  65 
USETEXT  81 
DOT  18 
SLASH  ta 

integer  a 

RP  16 
PLUS  so 
MINUS  67 
EOLC  10 
dollar  134 

/scanner  1 

/comment  keywords  not  INVOLVING  OUT  OR  STARTING  LINE»  TYPE  ILA 
/comment  CURV£(93)  sent  TO  SCANNER  11/  RECOGNIZED  BY  FSA 
/CLASS 

5AB0EFGHIJKLMNUP0RSTUVMXYZ 
5 EO  LP  RP  EOLC  COMMA 

5 C 

6 BLANK 

8 PLUS  MINUS  DOT 

8 DO  01  Oa  05  Da  05  06  07  08  09 

9ABCDEFGHIJKLNN0PQRSTUVWXYZ 

9 00  01  02  03  Oa  05  06  07  06  09 
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/FSA 

S1,EULC,EULC,S2 
$2,CUMMA,CUHMA,i5 
J5,EQ,EQ, AS 
SS,  LP»  ib 
Sb,HP,Rf»,$7 
1 

Stt.U, S9, S 
$9,R,$10,5 
SI  0, V, St  1 , 3 
St  1 ,E ,S12, 3 
S12/8, *t  1,3 
/KE YWUPD5 
X 105 
TWUD  96 
SCEPTME  127 
NET  127 
ClPCUS  127 
LUG  91 
R 97 

TARGET  126 

final 

linlhg 

LOGL  IN 
LUGLOG 
PCJLAR 
NYDUI ST 
GAUSS  103 
RECT  103 
TRI  105 
/SCANNER  2 

/cumment  fixed  length  keywords  and  special  Characters 
/comment  Identifier  (type  ilaj  is  formal  parameter  in  definitions  of 
/comment  subnet,  model#  function#  procedure 
/identifier  52 

/CLASS 

«ABCDEFGHIJKLMnOPC|RSTUVWXYZ 
2 DOT 

5 PLUS  MINUS  RP  DOLLAR  EULC  COMMA  SLASH  EQ 

5 LP 

6 ULANK 

8 star 

raocoefghijklmnopqrstuvwxyz  dot 

9 Do  D1  D2  D3  04  DS  06  07  D8  D9 
/KWLENGTH  1 4 5 

/KEYWORDS 


.LT. 

61 

.LE. 

61 

.GT. 

61 

.CE. 

61 

.Ell. 

61 

.NE. 

61 

. 18 
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.*<aT.  62 

.OR. 

.AND,  60 
/FSA 

51 ,  PLUS, PLUS. S? 

52,  MINUS, minus, is 
$ 5, slash, SLASH, S« 

50. CUMMA.COmma.SS 

55, EU.EU, $b 

56,  WP, HP, 57 

57, E0LC,F(ILC,58 

sa, DULL  AH, DULL AR, *R 
S9,LP,LP, 1 

/SCANNFH  5 

/comment  KEVRURDS  mITHUUT  Dir.ITS  (JH  DOTS,  STARTINC,  LINE,  AL-SU  CUMMtNl 
/comment  lexical  CUNSIHUCTS  which  may  START  A LINE 
/comment  class  a hecognues  numreh,  curve,  table,  standard 
/comment  elements,  model  reference,  subnet  reference,  comment 

/comment  (I.E.,  any  ill  IDA  COMMA  CONSTRUCT  AND  CERTAIN  ILL  IDA  EOLC 

/comment  constructs) 

/COmmeni  scanner  3 13  ENTERED  FUR  REAL  VAHIABL  DEFINITION  AND  KEYwIjRDS 
/comment  (ILA  ECl  CONSTRUCT)  BUT  ANALYSIS  DONE  IN  SCANNER  6 VIA 
/comment  esa  transfer 

/comment  scanner  3 IS  ENTERED  FOR  FUNCTION  DEFINITION  AND  KEYWORDS 
/comment  (IlA  lP  CONSTRUCT)  BUT  ANALYSIS  IS  DUNE  IN  SCANNER  10  VIA 
/COMMENT  FSA  transfer 

/comment  keywords  text,  USETEXT,  TADLE,  curve,  recognized  by  FSA.  table 
/comment  and  curve  Then  processed  by  class  a routine. 

/CLASS 

SABCDEFGMIJKLMNOPURSTUVWXYZ 

5 STAR 

a 00  Dl  D2  Di  Da  OS  Ob  07  08  DR  PLUS  MINUS  DOI  DOLLAR 

6 blank 

aAMCDEFGHlJKLMNOPORSTUVWXYZ 

9 DO  01  02  03  Oa  OS  Ob  07  08  09 

/FSA 

51 ,  T, sat ,527 
5ia, STAR, star, SIS 
515,5,515,516 

516,  COMMA, 3, 51 7 

51 7,  LP, *10, 518 

51 8,  EOLC, 3, 519 

519,  EO, *6,520 
520,8,521, t 

521.5.521.522 

522.8.521.523 
523, EOLC, 3, 52a 
52a, EO, *6,525 

525,  LP, *10,526 

526,  comma, 8, 1 

527,  U, 53a, 526 
S2R,C,529,Sia 
529, u, 530, SIS 


ITL 


$50,«,$S1,S1S 
Sil » V, SIS 
S Jt?»F  , $55,  $tb 
5i3,H,Sy5,$tS 
S54, S, Jib. St  b 
Sib,E,Sih,$lb 
Sib, r, Si;, SIS 
S57,E,$3S,$tS 
Sib,X,$J4,Slb 
Si'), r, $40,. Sib 
$'J0,M,  i,  $1  b 
$41, A,S42,Si/ 

$4^,H,$45,$lS 
$4i,L, $44, $15 
$44,t,$55,$lb 
$4b, 5, $45, 146 
$4b,8, S45,$4  / 

$47,FOLC,«, $24 
/KE  rwUKOS 
PHINf  HO 
ENDHUN  10') 

RUM  117 
SFAfE  11b 
DATUM  118 
SUBNET  <;9 
ENDENTEH  121 
ENTEWCIHCUS  94 
ENTERNEr  94 
EMTERSCEPTWE  94 
EMDSTATE  11b 
EMOOECK  107 
RUNMONTEC ARlU  108 
WUNUPTIMIZaTION  114 
MUDEL  123 
PL(Jr  89 
BUUNOS  115 
EMDMuOEL  124 
END  b9 

MUN,HJRS  ICASE  110 
DEVICE  125 

INI  T I aLCDNOI TIUNS  111 
ENDSUHNET  112 
PROCEDURE  98 
/scanner  4 

/comment  first  symbol  of  me 

/comment  class  8 ROUTINE  HANDLES  SIGNED  NUMBERS  (53),  PLUS ( 50 ) , M I NUS ( 6 7 ) 
/comment  keywords  beginning  with  dot  are  analyzed  by  scanner  2 THRU 
/comment  FSa  xfr 

/comment  FSa  recognizes  LP(15),  SLASH(14),  CUMMA(63),  EOLC(IO), 

/comment  D0LL*R(15^J 

/comment  KWl(l),  math  FUNC(122),  user  FUNCdiS),  KW9(79),  KW32(  102), 
/COMMENT  KWtt9(119),  KMb0(I20),  KW2(72),  KW4(74)  SENT  TO  SCANNER  10 
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/comment  heal  VaRIABLE(  152)  (TYPE  ILL)»  Kw7(77)  (TYPE  ILL),  KW20(<»0), 
/comment  KW?a(92),  KW55(105)  SENT  TO  SCANNER  6 

/comment  heal  variable  (t52)  (TYPE  ILA),  STANDARD  ELEMENT  (78), 

/comment  KW7  (7/)  (TYPE  ILA), 

/comment  subnet  REFERENCES  (131),  CURVE  (95)  SENT  TO  SCANNNEH  11 

/class 
6 blank 

SABCDFFGHIJKLMNOPtJRSTUVWXYZ 

5 DOT  LP  SLASH  comma  EOLC  DOLLAR 
8 00  01  02  03  Oa  OB  Ob  07  08  09 

0 PLUS  MINUS 
/F3A 

$1 , slash, Slash, $9 

S2, 8,8, *2 
S3,LP,LP,I18 
sa, COMMA, comma, 

$5,EULC,EULC»»B 
$t>,  OOLLAR,  DOLL  AH,  $7 
$7, DOT, $2, 45 
$8,  RP,  »6, 49 
S9,  SI.  ASH,  *6, 41  0 
$10, COMMA, *b, 41  1 
$1 1 ,E0LC, *6, $12 
$1 2, OOLLAR, *b, $ 1 9 
$1 3, PLUS, »6, $27 
$19, LP, *10, 41B 
$1B,OOT, *fa, 416 
$16,5, $8, $13 
$17,LP,*10,$18 
$18,OOT, *1 1,$19 
$1 9, SLASH, *11, $20 
$20, OOLLAR, * 1 1 , $21 
$21 , COMMA, *11, $22 
$22,EOlC,*11,$23 
$25, PLUS, *1 1,$29 
$29, MINUS, *11, $25 
$25,5, $17, $26 
$26, P, $1 7, * 1 1 
$27 , MINUS, *6, $28 
$28,8,41 7, $29 
$29,LP,*10, *6 
/SCANNER  B 
/COMMENT  ILL  type 
/IDENTIFIER  55 
/CLASS 

4AHCOE  FGHIJKLMNUPQRSTUVHXYZ 

6 blank 

9AHC0EFGMIJKLMN0PfJRSruVWXYZ 
/SCANNER  6 

/COMMENT  RECOGNIZES  KEYWORDS  AND  RFAL  VARIABLE  DEFINITION  ( LEXC0UE= I 32 ) 
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/comment  receives  control 

/CLASS 

5ABCDEFGHIJKL 
b BLANK 

RAHCOEFGHiJKL 
9 DO  D1  0?  D3  09  05  Db  07 
/IDENTIFIER  132 
/keywords 

OBJ  109 
TIME  77 
FREQ  77 
DELTAT  77 
NEUT  77 
gamma  77 
GAMDOT  77 
MAXSTEP  77 
mInSTEP  77 
terminate  77 
L inlog 

LOGLIN 

L3GLOG 

polar 

nyquist 


BY  FSA  XFH  FROM  SCANNERS  3 AND  9 

MNOPQRSTUVWXYZ 

MNOPORSTUVWXYZ 
D8  D9 


FINAL 

/SCANNER  7 

/comment  nude  name  processing  and  type  iaa  constructs 

/comment  element  NAMES(7B)  and  subnet  NAMES(131)  SENT  TO  SCANNER  11 

/IDENTIFIER  59 

/CLASS 


5 

ABC 

D E 

F 

G H I 

J K L 

M 

N n 

P 0 

R S 

T U V X Y Z 

5 

SLASH 

9 

DO  D1 

02 

03 

09  D5 

Db  07 

08 

D9 

b 

BLANK 

9 

ABC 

D E 

F 

G H I 

J K L 

M 

N 0 

P Q 

R S 

T U V w X Y Z 

9 

DO  01 

02 

03 

09  05 

Ob  07 

08 

09 

/FSA 

SI / SLASHr  slash*  S2 

S2*9*9*S3 

S3, SLASH, 9, $9 

S9,5,$3,S5 
$5,9,S3,S6 
Sb, DOT , *11,9 
/SCANNER  B 

/comment  element  parameter  symbols 

/comment  only  DIODE  PARAMETERS  INCLUDED 
/CLASS 

3ABCDEFGHIJKLMNOPQRSTUVWXYZ 
6 blank 

9AHCDEFGHIJKLMN0PQRSTUVWXYZ 
9 00  01  02  03  09  05  Ot>  07  DB  09 
/KEYWORDS 
C 7b 
CC  76 


ITT 


IPl  76 
IP?  76 
IS  76 
KIS  76 
KRfi  76 
KN  76 
N 76 
R8  76 
T 76 
TH  76 
VZ  76 
M 76 

/SCANNER  P 

/CUMMENT  TEXTLIST  (TERMINATES  WITH  EROTEXT  □«  ENOENTER) 

/CLASS 

8ABCDEFGHIJKLMN0PQRSTUVWXYZ 
8 00  01  0?  03  04  05  06  07  08  04 
8 PLUS  MINUS  star  slash  LP  RP  OOLLAR  EU  BLANK 

8 comma  OOT  EDLC 
/SCANNER  10 

/comment  RECOGNIZES  KEYwOROS  ANO  FUNCTION  OEFINITIONS  ( LE XC ODE = 1 33 ) 
/comment  RECEIVES  CONTROL  BY  F3A  XFR  FROM  SCANNERS  3 ANO  4 
/comment  HaNOLES  ILA  LP  CONSTRUCTS 
/lOENTlFIER  135 
/CLASS 

5ABC0EFGHIJKLMN0P0RSTUVWXYZ 
6 blank 

qABCDEFGHIJKLMNUPQWSTUVWXYZ 

9 00  01  0?  03  04  05  06  07  08  09 
/KmLENGTm  1 

/KEYWORDS 
LOG  1?? 

SORT  12? 
tan  122 
U 122 
ABS  122 
ATAN  122 
ATAN2  122 
COS  122 
EXP  122 
MAX  122 
MlN  122 
MUD  12? 

SIGN  122 
SIN  122 
complex  79 
RADIANS  79 
DEGREES  79 
SENS  71 
PT  119 
PV  119 
IV  119 
0 119 
S 102 


W 
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U Ic'd 
E 120 
F 120 
N 72 
A 

B 7b 

Y 75 
Z 75 
I 74 

V 74 
P 74 
/FSA 

St, [,S10,S2 
S2, V,S10,S5 
S3/P,S10,S4 

54, A,S10,S5 

55, B,S10,S6 
Sb, Y,S10,S7 
S7,Z,S10,SB 
SB,N, S9, 3 
S9,LH,2,S10 

510, M,S15,S1 1 

51 1, D,S15,S12 

512, P,S15,S13 

51 3, P,Sl5,Sl4 
Sl4,I,Sl5,3 
Sl5,LP,2r  3 

/scanner  11 

/COMMENl  RECUfiNUES  WEALNAME,  STANDARD  ELEMENT,  SUBNET  REFERENCES, 

/comment  curve  usins  Class  b routine 

/COMMENT  RECEIVES  CONlHOL  BY  FSA  XFH  FROM  SCANNERS  4 AND  7 
/CLASS 
b blank 

8ABCDEFGHIJKLMNOHQRSTUVRXY2 

9ABCDEFGHIJKLMN0PQR3TUVWXYZ 

9 DO  D1  D2  D3  D4  o5  Db  D7  DB  09 

/kE YRUROS 

CURVE  93 

TABLE  95 

ABS  7H 

AND  78 

A COS  78 

ASIN  78 

ATAN  78 

C 78 

CCNV  78 

CM  78 

0 78 

OOACC  78 
DELAY  70 
DERIV  78 
OF  78 
EUR  78 
E XP  78 
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EXPN 
GAIN  7« 

HC  78 
HO  78 
Hrsr  78 
I 78 

INPFL  78 
INT  78 
IPP  78 
JFET  78 
K 78 
L 78 
L IM  78 
LININT  78 
LUG  78 
MAX  78 
MC  78 
MFEr  78 
M I N 78 
MUO  78 
MULT  78 
NLVCCS  78 
NJ«M  78 
UR  78 
UUTFL  78 
PN  78 
QUANT  78 
K 78 
MAOC  78 
RMS  78 
RNGEN  78 
RSTFF  78 
3 78 

SAMPL  78 
SIGN  78 
SINCUS  78 
SNCLK  78 
3URT  78 
sr  78 
SUM  78 
f 78 
TA8F  78 
TANH  78 
TO  78 
TLINE  78 
V 78 
VCCS  78 
VCG  78 
VCVS  78 
XFCP  78 
XFCZCP  78 
XFCZDP  78 
XFP  78 


XF3P  7» 

XFZCP 
ZD  78 
XMUD  76 
YMOO  78 
/SCANNtW 

/CQMMfcNT  iNTEGtW  AND  KWbA(l^a) 

/CLASS 

2 M D H K I 

5 LP 

6 blank 

8 DO  D1  0<^  Di  0^1  Db  Db  D7  DH  D9 
/K ^length  1 
/K£ YrtUROS 
M I 
P U6 
H 128 
I 128 
0 1 28 
/FSA 

Sl»LP»LPr  1 
/End 
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APPENDIX  G 


NET-2  GRAMMAR 


This  appendix  lis'^s  the  grajnmar  for  the  NET-2  language  using  BNP 
notation  which  is  consistent  with  the  input  to  the  LR(k)  Parser  Generator. 
A listing  of  the  undefined  terminal  symbols  and  their  corresponding 
character  strings  is  given  below: 


Lexical  Symbol 


Character  String 


ACPFX 

ARG 

B 

CIRCPFX 

DEVPFX 

DRTYPE 

EOLC 

GLOBAL 

ILL 

INTEGER 

MATHF 

NUMBER 

PARAM 

PRIME 

RPFX 

SINT 

SUFFIX 

SYSPFX 

T 

TEXT 

TYPE 


A,  A' , B,  B' , Y,  Y' , Z,  or  Z' 

Any  alphameric  identifier,  starting  with  a letter, 
which  may  serve  as  a formal  parameter 

One  or  more  blanks 

Any  of  the  standard  circuit  element  prefixes,  not 
including  the  modeled  devices 

Any  of  the  modeled  device  prefixes 

Any  of  the  data  reduction  types,  e.g.,  DC,  CT,  etc. 

End  of  logical  card  symbol 

Any  global  variable,  e.g.,  FREQ,  TIME,  TERMINATE,  etc. 

Any  identifier  composed  only  of  letters 
Any  unsigned  integer 

Any  standard  mathematical  function,  e.g.,  SIN,  COS,  etc. 
Any  real  number  representation 
Any  device  parameter 

Any  element  response  variable  prefix,  e.g.,  I,  V,  P,  etc. 
An  integer  with  a mandatory  + or  - sign  prefix 
Any  alphameric  identifier,  starting  with  a digit 
Any  system  element  prefix 

A tab  or  indentation,  consisting  of  ^ fixed  number  of 
blanks 

An  arbitrary  character  string 

Any  alphameric  identifier,  representing  a device  type 
name 


a 
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The  complete  description  of  the  NET-2  grammar  is 


/comment  net-2  G«AMMA» 
/DE'BUG  18 

/lexical 

T 10 
B 1 1 
EULC  12 
ACPFX  13 
ARG  1 a 

CIHCPFX  16 

DEVPFX  17 

DRTYPE  18 

GLOBAL  19 

INTEGER  20 

NUMBER  21 

PARAM  22 
RPFX  25 
SUFFIX  2a 

SINT  25 
SIMPNUOE  2b 
SYSPFX  27 

TEXT  28 
TYPE  29 
WORD  30 
SEND*  51 
32 

S-S  33 
S,S  3a 
S.$  35 

SMUOES  3b 
SKS  37 
SLS  58 
SCHJ  39 

SMcs  ao 
s*s  at 
S = S 92 
SFREiJS  93 
STERMINATEi  aa 
SMAXSTEPS  as 
SOEBUGS  4b 
STLIMJ  47 
SCORVEi  48 
SUATAS  49 

soefines  so 

SALLS  51 
SOISTS  52 
»i)ELETES  53 
lOPLS  54 
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iPRINTS  Sb 
*LPS  Sh 
*LDS  bf 
$($  5» 

$)S  bR 
SF$  60 
tCUPYS  bl 
SLIHRARYS  62 
SSMLS  63 
SMONTECARLUl  6Q 
SI  IRES  65 
SPLUrS  67 
$**S  68 
SHOOELS  69 
lOfPS  70 
SRONES  71 
S/S  72 
SU8JS  73 
SUPTIMIZES  7« 

SSTATES  75 
SVSS  76 

SPARaMETERS  77 
SPS  78 
SL INLUGS  79 
SLUGLINS  80 
SlOGLOGS  81 
SPOLARS  82 
SRS  83 
SGAUSSS  89 
SRECTS  85 
STRIS  86 
SXS  87 
PRIME  88 
SRS  H9 
SPIRALS  90 
MAIHF  91 
SCASESS  92 
STABLES  93 
/8NF 

R'JNsOECK  SENDS  EULC 
AL)P  = S»S 
AJPsS-S 
ARGL I STsARG 

ARGLISI=AMGLIST  S,S  ARG 

CASEsSCASESS  h integer  EOLC 

CHANGE  I sELVaL  8 NUM2  EULC 

change  1 sDEVNAME  S.S  SMUDES  B MUOtl  EULC 

CIRCELEH=C IRCPFX  SUFFIX  B PARSED  8 NUOELlST  H VALUELIST  EOLC 
CIRCElEM=CIrCpFx  suffix  8 NUOELlST  H VALUELIST  EULC 
CIRCELEMsjkj  suffix  H SLS  SUFFIX  8 SLS  SUFFIX  8 VALUE  EULC 
CIRCELEM=SCnS  suffix  B NUOELlST  H SMCS  SUFFIX  8 VALUELIST  EOLC 
C'JMMENr  = S*S  TEXT  EULC 
CUNSTHAINT=FLVAL  S=S  me  EULC 
CUNSTRAlNisSFREUS  $cS  HE  EULC 


CONTHUL=STERMINa  rEJ  S = $ ME  ECJLC 
C0NTRUL=SMAXSTEPX  S=5  me  eolc 
C JNTRUL  = iOEBUC,S  H INTEGER  EULC 
C(JNTRfJL  = STLlMS  B NUMBER  EULC 

CURVrSCUWVE  .t  SUFFIX  EULC  T NUMBER  H NijMl  EULC 

cuRv  = f.;uRv  r number  b numi  eui.c 

DAlAl=r  T SUAlAi  B URIYPE  EULC 

datai=t  t soatas  h uriype  b param  eulc 

OATAlsDAfAl  T T T NUmSET  EULC 
DECK=ENTRY 

deck=deck  entry 

DEFENT=SUBNETREF 

defent=element 

DEFEN  TsXDEF 
defent=symcun 

OF  INE  = 4DEF  INE»  B SUbNETPFX  FJ  OUMNUUELIST  EULC  T DEFEnT 

dfine=ofine  T oefent 

OEVIC6=DEVPFX  SUFFIX  B PARSED  B NUDELIST  H TYPEl  EULC 
DEVICE  = DEVPFX  SUFFIX  B NOOELIJir  B TYPEl  EULC 
DEVLISTsT  r OEVPFX  B TYPE  EULC 

devlistsoevlist  t t devpfx  b type  eolc 

DEVLIST1=0EVLIST 
DEVLlSTlcT  T SALES  EOLC 
DEVNAME=NEST  S.S  OEVPFX  SUFFIX 
DEVNAME=DEVPFX  3UFF1X 

DiSTOEFsSOISTS  SUFFIX  EOLC  T NUMI  EOLC 
DlSTOEFsOlSTDEF  T NUMI  EOLC 
DLIB0EL=T  SOELETES  B SQPLS  EULC  0EVLI3T 
DLIBPRINTsT  sprints  B SOPLS  B integer  eolc  OEVLISTl 
DLIBPKINT=T  SPRINTS  B SOPLS  EOLC  OEVLISTl 
OUMNODEL ISTsSiMPNOOE 

OUMNUDELIST =OUMNODELIST  B SIMPNUOE 

ELEM=ELPFX  SUFFIX 

element  =CIRCElEM 

ELEMEnTsSYSELEM 

ELEMENTsDEVI CE 

ELNAME=ELEM 

ELNamEsNEST  S.S  ELEM 

ELPFXsC IRCPFX 

ELPFXsOEVPFX 

ELPFXsSYSPF  X 

ELPf R=ELPTR1 

ELPTRsELPTRl  SINT 

ELPTR1=SLS 

ELPTRlsSLPS 

ElPTRI =SLOS 

ELVAL=ELNAME 

elval=elname  S.S  integer 

ELVAL=ElnAME  S.S  PARAM 
ELVAlsELNAME  S.S  SIS  ElPTR  S)S 
ENTRYsDF INE 
ENTRY  = SUUNE  IHEF 
ENTRYsELFMEN  T 

ENTRYsSFREUS  h number  eulc 


m 


ENTRY  = SULf4 
ENTRYscQNTHUL 
ENTRYsC JMMENT 
ENTRYsTAHf  L 
ENTRY=CUWV 
ENfRYsOISrOEF 
E NTRYrXOtF 
ENTRY  = SYMC(JN 
ENTRYrFUNC 
E NTRYsPHME  TER 
ENTRYrLlH 
EN  fRY  = MUuE  LDEF 

FUNC=SFS  SUFFIX  $($  aRGLIST  S)s  S=$  ME  EOLC 
LlBCOPYsT  SCUPYi  B LIBTYPE  EDLC 
LlHENrsULIHPWlMf 

LlaENTrLIHSPEC 
LIBENr=DLIBDEL 
LlBENT  = LIbCl)PY 

libent  = slhjdel 

libent=slibprint 

L IB=SL IBHAHyS  EOLC  LIBENT 
LIB=LIfl  LIBENT 

LlB3PtC  = T OEVPFX  8 TYPE  B INTEGER  EtJLC 

L IB3PLC=L  IB3PEC  T T PARAM  B NUMhER 

LIBSPEC=LIBSPEC  T T QATAl 

LI8TYPE=SDPLS 

LIBTYPEsSSMLS 

MARG  = UU  r VAR 

MARGsNIJMBER 

M ARGsAHG 

MCI =5muntecaRLQ*  inieger  EULC  T MCENT 

MC1=MCI  T MCEnT 

MCENT=CHANGE 1 

mCENT  = STA  T 

mCENT=CASE 

MCENTssriMEl,  B NIJM2  EULC 
MCENt=SFRE(U  b NuM2  EULC 
MCEN  TsMCUUT 

MCOUTsSPRInTJ  b UUTlSI  EULC 

MCUUTrSPLflTi  B OUTVaR  EULC 

M£  = A(JP  mTERH 

mE=MTERM 

ME=ME  AUP  MIEHR 

MF AC  TURsMF  AC  fUR I 

MFACTUHsMFAC fORl  5**S  MFACIURl 

MFACTI)W1=$(S  ME  »)» 

mfacturi=marg 

MFACTURlsMFlJNC  1(S  VaLUELIST  i)J 
MFUNCsMA IMF 
mFUNC=JF$  SUFFIX 

M'JOELUEF  sJMilDEL  i B SlJBNETPFx  B DUMnUDELIBT  EULC  T MUUELENT 
MOOELOEF=MOoELDEF  T MUuELENf 
MUUELENisSUrtNE IREF 


186 


MJDELhN  I =FLE«F.NI 
MODtlENl =XDf F 
MUOEl,  tNf  = SYMCr)N 
MUOELENT=TAbEL 
hODElE  Nl  =MJnC 
HJDELEN  r=OF  FNL 
MJDt  1 = J»UF  F S 
MJDf.  1=$N(JNE5 
m3P  = $ * :k 
HJH'rS/S 

M r t mh  = mf  AC  ruK 
HrE«M=MTEKM  Mup  mfact:jk 
NES  r = s(iUNt  r 
NEST=NESr  $.i  subnet 
NUL>ErSI‘1HN/JDfc 
NDUE=NESI  SIMPNUuE 

NUDEL  IST=NOl)£ 

NUf)ELIST=NUOELlsr  0 NUDE 
NUnSE I =NUM0EH  Q NUMdtH 
NUHSE TsnUmSE T a NUMBEK 
NUM  1 =NlJNHt  M 
NUMi=NUMi  a NunaEM 
NUM^  = NUM»^.R 
NUH2=NUHbEW 

UBJCTzSURJS  s=s  me  edlc 
□aJCT=$UbJS  i=4  me  UbJl  EULC 
l)BJl=b  4CUKVES  SUFFIX  b NUMbEK 
i)Bji=B  icumvEx  suffix  H NUMHEK  b SX* 
OPr=tUPl IMI2EI  INTESEM  eolc  t optent 

UPT=UPT  T UPTENI 
OP  I EN  T =P ANCE 
OPTENfcCnNSTRAlNT 
UPTEnTsQPTST ATE 

UPTSTATE=SSTATE»  EULC  T T UPTSTATENT 
0PTSTATE=UPTSTATE  T T uptstatent 
OPSTA  TENT  = CMAN(iE  1 
OPTST ATENT=ELV AL  B SWNUH  EOLC 
OPTSTaTENTsSTIMES  b SWNUM  EOLC 
UPTSTaTEnTsIFMEUS  B SWNUM  EULC 
OPTS r aTENT=PCDN  B S«NUm  eolc 
OPTSTaTEnTsORJC  T 
OUr=T  sprints  JUTlST  EULC 
UUTsPLUTt  b IJUTlST  EulC 

OUTsPLUTl  B OUTL5T  b SVSS  b OUTVAP  EOLC 

0UTLSI=UUTVAP 

DUTLSTsOUTlsT  B UUTVAK 

UU  r V APrELV AL 

outvak=rvar 

OUrVAH  = (iLUBAL 
L)UTVAK=XVARnAME 
OUT VARSPCON 

PRME TERsSPAMAME TERS  EULC  T CHANGtl 
PRMETERsPRME TER  T CMaNGEI 
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PANSEiJ=S(i  IMEfiLW  *)* 

PCUN=SP4  SUF  F I X 
PLUT  T yPEsiL  I NLUti* 

PLUrTYP£  = iLJGLlNl. 

PLUT  TrPL  = 4i.UC,L  Jl«i 
PLUI T YPt=  iPULAPi 

PLOT  UiPLUr* 

PLUT1=4PLUT4  B PLOirYPt 

WANCiEsWANGF  1 8 NIJMc?  U NUPi?  EMLC 

WANGtlxELVAL 

WANGE  UiFPEQS 

MANGE  1 =PCUN 

MVAM=$nJ  4(4  node  S)$ 

RVARzaCPEX  J(4  nude  S-4  NODE  4/4  NODE  4-S  NODE  4)4 
HVAWzMPFX  4(4  ELNaME  4)4 

SLlHDEL=r  40ELE(E4  a *SML4  EOLC  T T SUBNETPFx  EOLC 
SLIBDEL=3LIBDEL  f ( SOdneTPEX  EOLC 

SLIBPMINfsr  sprints  ti  SS8LS  B INTEGEM  EJLC  T T SUBNETPFX  EOLC 
SLlBPMINTsT  SPRINTS  B SSMUS  EOLC  T T SUBNETPFX  EOLC 
SLIBPMINTsSLIBPMINT  T T SUBNETPFX  EOLC 
SJLN=3TATE I 

solnzmci 
SULNzOP  T 

STATzSTATl  B STAT^  NUM<>  EOLC 
STi TdEL IM=h 
3 F A I DEL  IM  = S* 4 B 

STA1E1=5STaTES  INTECiEM  EOLC  T STATENT 

STATE1=STATE1  T state  NT 

3TATEnT=T  changei 

STATENT  = T STATENTI  B SwNUM  Ef)LC 

5TATENT  = T S*S  STATENTI  B Swnijm  EFILC 

STaTENTsOUT 

STaTENTsSF IMES  d SWNUM  d SFINAL4  EOLC 

STaTENT=ST IBES  d SFINAL4  EOLC 

STaTENTIzELVAL 

STATFNTIzSTIMES 

S T A I ENT  1 zjFhEDS 

STATENTlzPCjN 

STA  r IzELVAL 

SrATlsSTlHE4 

3TaT IsSFREOS 

3TA  T 1 sPCUN 

3TaT2=4GAU3SS  3TaTDELIM 
STAT2=SHECT4  3TAT0ELIM  NUM2  B 
3TAT2s$TRI4  STATDElIH  NUH2  B 
3TAT2=S0ISTS  suffix  SFATOELIM  NUM2  8 
3UBNE T=3UHNE TPFX  SUFFiX 
SUflNETPFXsWQKD 

SUbNETREFsSUBNE r B PaMSEU  B NUOELIST  EOLC 

SUflNE TREFsSUBNE r B NOOELtST  EOLC 

3NNUH=NUm2 

3NNUm=3NnUm  U NUm2 

snnum=3mnun  4(4  Integer  t)s  nun2 

Snnumssnnum  4(4  Integer  t»%  $)%  nuh2 
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SYMCQNsSPS  SUFFIX  B NUM8EW  EULC 
SYMLISTsUUTlST 
SYMLISTrSTABLES  SUFFIX 
SYMLISrsSMCS  SUFF  IX 
SYSELEMsSYSPFX  SUFFIX  EULC 
SYSElEM=SY3PFX  SUFFIX  SYSl  EULC 
SYSl=B  NUDElIST 
SYSl=B  NUOELIST  SYS2 
3YSl=SYS^ 

SYS^rB  VALUELISr 
SYS^sB  valuelist  a symlist 
SYS2=d  symlist 
TABEL=TABLE 1 

TABElsTaBEl  t numbeh  B SK$  edlc 
TA8EL=TABLE2 

table 1=$TAHLES  suffix  EULC  T NUMBEk  B NUMBER  EULC 
TABLE  I = TABLE  I T NyMBEk  B NUMF^ER  EULC 

T ABLE2=STaBLES  SUFFIX  B INTEGER  EULC  T NUM3EI  EOLC  T NUMSET  EULC 
T ABLEa  = TABLE«?  T NUMSeT  EULC 

typei=type 

TYPEIsTYPE  8 MUUE 

TYPE1=TYPE  B NUMBER 

VALUE=NUMBER 

VALUE=ME 

VALUELISIsVALUE 

VALUEL ISl sVaLUELIST  S,S  VALUE 

XDEF=$XS  suffix  $=J  me  EULC 

XOEF=$XS  PRIME  SUFFIX  S=$  ME  EULC 

XVAR=$XS  SUFFIX 

XVAR=$XS  PRIME  SUFFIX 

X VARNAmE=XVAR 

XVARNAME=NEST  $.$  XVAR 

ZENO 
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AO-A033  296  BOM  COMP  CL  PASO  TCX 

ON  The  0CS16N  OP  AN  EXECUTiV! 

SEP  76  A P MALMBER6 


UNCLASSIFIED  KM/E-OT-TS-F-OOIT 


END 


DATE 

FILMED 

2-^77 


I 

I 

I 


APPENDIX  H 


SCEPTRE  GRAMMAR 


This  appendix  lists  the  grammar  for  the  SCEPTRE  language  using  BNF 
notation  which  is  consistent  with  the  input  to  the  LR(k)  Parser  Generator. 
A listing  of  the  undefined  terminal  symbols  and  their  corresponding 
character  strings  is  given  below: 


Lexical  Symbol 


Character  String 


AND 

AOP 

CONSTANT 

DERIV 

BOLC 

lAA 

ILA 

INTEGER 

INTPAR 

IRA 

KWDTABLE 

KWEQN 

KWEXP 

KWG2 

KWG2A 

KWG2B 

KWGU 

KWG5 

KWG6 

KWG7C 

KWG7D 

KWICSH 

KWMODOPS 

KWOUT 


.AND. 

+ or  - 

A SCEPTRE  Constant 

D or  DERIVATIVE 

End  of  logical  card  symbol 

Any  alphameric  identifier 

Any  alphameric  identifier  starting  with  a letter 
Any  unsigned  integer 

Any  Internal  parameter  name,  e.g. , XSTOPT,  XIR,  etc. 

Any  alphameric  identifier,  beginning  with  the  letters 
A throiagh  H or  0 through  Z 

T,  TABLE,  or  DIODE  TABLE 

Q,  EQUATION,  or  DIODE  EQUATION 
X or  EXPRESSION 

R,  L,  C,  E,  or  J 
V or  I 

DE,  DJ,  or  M '■ 

P or  M 

J,  P,  VR,  VC,  VJ,  IR,  IL,  or  IE 

R,  E,  J,  or  P 

VC  or  IL 

R,  E,  or  J 

VC,  VJ,  or  IL 

PERM,  TEMP,  or  PRINT 

DEGREES,  RADIANS,  COMPLEX,  or  NYQUIST 
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Lexical  Symbol 

Character  String 

KWRCl 

A 

rmi 

control 

identifier 

KWRC2 

A 

run 

control 

identifier 

KWRC3 

A 

run 

control 

identifier 

KWRCl* 

A 

run 

control 

identifier 

KWRC5 

A 

run 

control 

identifier 

KWRC6 

A 

run 

control 

identifier 

KWRC7 

A 

run 

control 

identifier 

KWRRCl 

A 

run 

control 

identifier 

under 

RERUN 

KWRRC2 

A 

run 

control 

identifier 

under 

RERUN 

KWRRC3 

A 

r\in 

control 

identifier 

under 

RERUN 

KWRRCl* 

A 

run 

control 

identifier 

under 

RERUN 

KWRRC6 

A 

run 

control 

identifier 

under 

RERUN 

KWRRCT 

A 

run 

control 

identifier 

under 

RERUN 

KWTABLE 

T 

or  TABLE 

KWVAR 

R 

. c. 

L,  E,  J 

, M,  DE,  or 

DJ 

MFUNC 

Any  standard  : 

mathematical  function,  i 

MOP 

« 

or 

/ 

NOT 

.1 

MOT. 

NUMBER 

A 

SCEPTRE  Number 

OR 

.( 

DR. 

RELOP 

EQ., 

.NE.,  .1 

GT  *9  • G£ • 9 

.LT.,  or  .LE 

REMARK 

An  arbitrary 

character  string 

The  complete  description  of  the  SCEPTRE  grammar  except  for  features 
associated  with  CONTINUE  and  RE-OUTPUT  is: 


/COMMENT  SCEPTRE  GRAMMAR 

/DEBUG  16 

/LEXICAL 

SENDS  1 

EOLC  2 

OR  5 

RELOP  a 

S(S  s 

STS  6 

NOT  7 

AND  8 
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tCI»CUlTOESC«IPTlONl  9 
REHAHK  10 
CONSTANT  11 

S,%  12 

SDEFInEDPARAHETEKSS  li 

sss  la 
SPS  IS 
lAA  16 
number  17 
SGPS  17 
SMS  19 
IRA  20 
KNU2A  21 
KMG2  22 
SKS  2i 
SFCUNVS  24 
SMS  2S 
S-S  2b 
S*S  27 
SRS  28 
SJS  29 
DERiy  30 
ILA  31 
SHOUELS  32 
SELEHENTSS  33 
SES  34 
SFREQS  3b 
KNTABLE  37 
KNEON  36 
SFUNCTIUNSS  39 
SOS  40 
KMG2B  41 
SriHES  42 
KMC4  43 
KMG5  44 
KNGb  45 
KMC7C  47 
KNC70  46 

SINiTlALCONDiriUNSS  49 
INTEGER  50 
SMUNTECARLUS  51 
AOP  52 

S**S  53 

SMOOELOESCRIRTIUNS  5S 
SINITIALS  5b 
SPRINTS  57 
KMMOOOPS  56 
SCHANGES  59 
SSUPPRESSS  bO 

tALLf  61 
iPERMS  62 
STENPS  63 
NOP  64 


SOPl IH1ZATI3NS 
SUUTPUrSS  66 
SPLOTS  67 
KNUUT  66 
KNKCl  69 
KNKC2  70 
KWRC5  71 
KPHCO  72 
KWHC5  75 
SIFI  7a 
KMHC6  7$ 

KWMC7  76 

SRURCUNTKULSS  77 

SREHUNOkSCRIPTIUNS  79 

KNICSH  79 

KNRRCl  90 

KMRRC2  8t 

KMRRC5  82 

KMRHCa  85 

KNRRC6  84 

KMRHC7  85 

SSENSiriVlTVS  86 

KNDTABLE  87 

KMVAK  88 

SMURSTCASES  89 

SFS  90 

KREXP  9J 

INTPAH  92 

MFUNC  95 

S/S  94 

SLl  9S 

TYPE  96  ‘ 

/BNF 

OECKsHUDHO  sends  EOLC 
deckscirmo  sends  eolc 
OECKsMODHO  CiPHD  SENDS  EOLC 
DECKsHUDHD  ClPHD  RERUNHD  SENDS  EOLC 

deckscirhd  rerunho  sends  EULC 

BEXPsBfERM 
BEXPxBEXP  UR  BrERH 

bfactursne  relup  me 

BFACTIJHsS(S  BEXP  S)S 
BFACTURxNUT  bfaciur 
BTERMxBFACTOR 
BTERMxBfERM  AND  BFACTUR 
CHCLSTxCHGLSTl 
CHGLSTxCHCLST  CHGLSTl 
CHGLSTtxELEMCH 
CHCLSTlxDEFPAK 
CHGLSrixFUNCCH 

ClRHOxSCJRCUlTDEScPlPnONS  EULC  CUMHENr 
ClHHDxSclRCUlTDEScRlPTlONS  EULC 
ClPHOxClRHD  CIRHOl 
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ClRHDlsELEHSH 

ClRHOlsDE^PAHSH 

CIRHOlsJUTSH 

CIRKOlzICSH 

ClRHOlzFUNCSH 

ClRHOlsRCSH 

CIRHOlsSENSSH 

CIRHOizNCSH 

ClRHOlsMCSH 

ClRHOlzQPT 

COMMENTsREHAHK  EULC 

CUMHENTaCOHMENT  REMARK  EULC 

CONLSTaCONSTANT 

CUNLSTaCONLST  S*S  CONSTANT 

OEFPAHaOEFPARl 

OEFPARaOEFPAH2 

DEFPAR8DEPPAH3 

OEFPARsDEFPARa 

OEFPaRSHsSDEEINEDPARAMETERSS  eolc 
oeepaRsmsoefpawsh  oefpah  eolc 
OEFPARIsOP  SaS  VALUE 

DEFPARiiaSPS  UA  SaS  NUHBER  S(S  NUH2  S)S 

DEFPAHSaSGPS  lAA  SaS  CPLIST 

OEFPARitaSNS  lAA  SaS  DEFPARaO 

DEPPAHaOaOP 

DEFpARaOaTAUNAME 

DEFPAHaOaONAME 

OEFPARdOaXNAME 

OEFPARaOaXFUNC 

OEFPAR<l0aS(S  ENTRY  S,S  ENTRY  STS 

OEFPARaOal YPE 

DPaSOPS  lAA 

DPsSPS  lAA 

OUHVLSTalKA 

OUNVLSTaOUNVLSr  S,S  IRA 
DVARaKNG2A  KWC2  UA 
OVARaOP 

ELENaSKS  lAA  S,S  NOOELST  SaS  SFCUNVS  ELEM3  S(S  CONSTANT  STS 
ElEHsg2  Sf%  NOOELST  S>S  VALUE 

ELEHaSHS  UA  S#S  SLS  IAA  S-S  SLS  IAA  SaS  VALUE 

ELEMaKHG2A  UA  S#S  NOOELST  SaS  CONSTANT  S*S  ELENS  SRS  UA 

ELENaSJS  UA  S,S  NOOELST  SaS  VALUE  S*S  SJS  IAA 

ELEMaOERIV  ELEMi  SaS  VALUE 

ELEHalLA  S»S  NOOELST  SaS  SMOOELS  UA 

ELEHalLA  S*S  NOOELST  SaS  SMOOELS  UA  S(S  HOOOPS  STS 

ELENaeLEMR  IAA  S,S  NOOELST  SaS  NUMBER  S(S  NUN2  STS 

ELEMaELEMi  UA  S»S  NOOELST  SaS  S(S  ENTRY  S«S  ENTHYl 

ELEMCHaSKS  UA  SaS  SFCONVS  ELEM3  S(S  CONSTANT  S)S 

ELEMCHaG2  SaS  VALUE 

ELEMCHaSNS  UA  SaS  VALUE 

ELEMCH8KHC2A  IAA  SaS  CONSTANT  S*S  ELEH3  SRS  UA 
CLEMCHaSJS  UA  SaS  VALUE  S*S  SJS  IAA 


ELCHCHsDEKIV  ELEH3  SsS  VALUE 

ELCHCHSELEH4  lAA  $sS  NUMUEK  S($  NUM^  $)S 

ELEMCHsELEMi  lAA  1=$  S(S  ENTRY  S*S  ENTRYl 

elehshsselenentss  EOLC 

ELEHsHsELEMSH  ELEM  EOLC 

ELEM3SSES 

ELEM3sSJS 

ELEH4SELEM3 

ELEN4SSRS 

ENTRVsCONSTANT 

ENTRYsSFREOS 

ENTRYxKNrAtTLE  lAA  S(S  64  S)S 
EMTRYsOP 

ENTRYlsENTRY  S)S 
ENTRYisENTRY  S)S  S#S  TYPE 

FUNCsKNEQN  lAA  S(S  DUMVLST  STS  SsS  MEi  EOLC 

FUNCCHsKMTABLE  lAA  SxS  KNTABLE  IAA 

FUNCCHskHEON  IAA  SsS  KMEQN  lAA 

FUnCSHsSFUnCTIONSS  eulc 

FUNCSHsFUNCSH  func 

FUNCSHsFUNCSH  TABLE 

GPLISTsCPLISTi 

GPLISTsgPLIST  gplisii 

GPLiSTlssPs  lAA  S*S  SOS  GPLIST2 

GPL1ST?sgS 

GPLIST2SG6 

GUOP 

61SG2 

G13KHG2A  G2 

G1SKHG2B  IAA 

GlsSTIMES 

GlsSFREOS 

GlslNTPAR 

G2SKMG2  IAA 

63s6| 

G3STABNAME 

GisCONSTANT 

G31STsGi 

G31STSG3IST  S,S  G3 
G4sg? 

G4SKMG4  IAA 

cassriMES 

64ZSFREUS 

G4S1NTPAR 

GSsKNGS  IAA 

GSlSTsGS 

GSISTsgSIST  %,l  G5 

G6SKMG6  IAA  , 

G61STSC6 

G61STsG6IST  S,S  66 
G7s62 

67sSHS  IAA 
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G7af)P 

C7xKMC?A  KNG2  lAA 

G73SMS  lAA 

G/sSns  KMG7C  IAA 

G7sINTPAH 

G7SKWG7D  SKS  IAA 

G7sKMG?A  KWG7D  SKS  lAA 

ICSHsSINITULCONOiriONSS  EOLC 

ICSHsICSH  KMICSH  IAA  Ss$  NUHBEP  fULC 

INTLSTsINTEGEM 

iNfLSTslNTLST  S*S  INTEGER 

NCSHzSHUNTECARLUS  EULC 

MCSHsMCSH  VAHsET  £0LC 

HEsADP  HTERM 

MEsHTERH 

me=me  AUP  mtern 
mfactdmsmkactori 

MFACTUHsMF  ACIOHI  S**S  HFAdURl 
NFACTUR1sS(S  he  S)S 
NFACTURlsCONSTANT 
MFACTOMlsIRA 

MFACrORlsNFUNC  S(S  VaLUELIST  S)S 

MOOENTsCUMHENT 

NODENTrELEHSH 

huoentsocfpahsh 

MUOEnTsOUTSH 

HUOEnTsFUNCSH 

HUOENTslCSH 

HOdHOsSMODELDESC^^IP^IONS  EOLC 
NOOHDbSMIIOELDESCRIPI  IONS  S(S  HOOHDt  S)S  EOLC 
NUOHDaMUOHO  HQOL 
NOOHDlsNUOHO^ 

NOOHOIsNUDHD^  S*S  NU0H02 

HU0H02sSlNlTIALS 

HUOHOZsSPRlNTS 

HOOLsSHOOELS  IAA  S(S  MODTYP  S)S  S(S  NUDELST  S)S  EOLC 

NOOLsSNOOELS  IAA  S(S  NODELS*  S)S  EOLC 

NODLbHODL  mjdent 

HOOUPSsNUOOPSl 

MUOUPSsHUUOPS  S»S  MOOUPSl 

hooopsi«kwnuoops 

NUOUPSIsSCHANGES  CHGlST 
NUOOPSIbSSUPPKESSS  OUTLSr 
MOOUPSlsSSUPPRESSS  SALLS 
HODTYPsSPERHS 
moot YPbSTEHPS 
NTERNsHFACTOR 
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MTEHMsmTFKh  MJP  HFACTJH 
NjOELSIslAA 

NUOfcLSrsNUOfLST  S-S  UA 
NUML3T  s^^UMLST  I 

numlsisnumlst  s,s  numlsh 

NUMLST I sNUMtttH 

NLlMLSrisNUMtiEH  S(>  NUMbEW  SfS  NUMBER  S)S 
NUMlsNUMRER 

nuhi=numi  %,%  number 

NUMi»  = NUMHE  R 

NUM^sNUMHER  &,$  NUMBER 
• OPTsSUPTIMI/ATIUNS  EHLC 
OPTsUPT  VaRSET  EULC 
OUrsUUTLST 
UUrsfJUTLST  UUTi 
OUTsoUTLSI  0UT2 

outlst=outi  sn 

OUTLSTsJUTLST  S,S  UUTLSTl 
OUfLSTl=f;7 

UUTLSMs&7  $(S  IAA  S)S 
OI^TSHsSUUFPUTSS  EULC 
OUTSHsOUTSh  out  EULC 
OUTl=S,S  SPLUrS 
OUMs$,$  SPlOTJ  UUTi 
OUT(»  = S>S  KMUUT 

ourassrs  kmuut  uut4 

UUT2=UUTa 
UUT3S I AA 

UUTisIAA  UUTLSTl 
UUT5=UUTLSTI 
UUT4=S»$  SPlUTS 
0UT4=S,S  SPLUTS  lAA 
ONAMEsKWEON  UA  S(S  G313T  $)$ 

KCsKMKCl  %s%  number 
RCSKHKC2  SsS  KNRC3 
RCsKMRCa 

RCsKMRCS  SIFS  S(S  BEXP  S)S 
RCsKHRCb  $sS  INTEGER 
RCSKMRC7  SxS  CONSTANT 
RCSHsSRUnCOnTROLSS  EULC 
RCSHsRCSH  RC  EULC 
RERUNHDsSRERUNOESCRIPTIUnS  EULC 

REHUNHDsSRERUNDEScRIPT IONS  S(S  INTEGER  S)S  EOLC 

RERUNHDxRERUNHD  RRUN 

RHC1R=»ELEMENTSS  EOLC 

RRClRsRRCIR  RRClRl 

RRCIR1SG2  SsS  NUMlST  EULC 

RRDPsSDEFInEDPARAmETERSS  EULC 

RRDPsRRDP  RHOPl 

RROPlxOP  SsS  NUMLST  EULC 

HRFUNCsSFUNCTIUNSS  EULC 

RRFUNCsRRFUNC  RRFUNCl 

RRFUNCIsKMTAHLE  UA  S«S  NUMl  EOLC 
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HRFUNC 1 sHHF JNC  1 NUMl  EULC 

RRIC  = klNI T1  At  CUNOI riUNSS  EULC 

R«IC=«HIC  RHICI  tULC 

RRIC  isKWKS'i  S = S NJNl 

RRRCsIRUNCUnTRJlSS  EIILC 

RRRC=RRKC  RRRC  I EULC 

RRRC  I =K*<RHr.  1 SsA  NUMlST 

RRRCI=KWRRc?  K*<HRC5 

RRRCl=KWKRCa 

RRRCl=KHRRCb  S=S  INIlST 

RRRClsKrtRRC/  $=*  CONL3f 

RRUNrCUMMf  N f 

RRUNrHRC IH 

RRUNsRRDP 

RRUNsRRIC 

RRUN=RRFUNC 

RRUNirRRRC 

SENSSHriSkNSi  TIVITfi  EtJLC 
SENSSH=SENSSH  VAHSEI  EULC 
TABLEsKi^f)TAiU.E  IAA  EULC 

tablesFable  number  s»»  number  EOLC 

T ABNAMEsKHTaBLE  IAA 

TABNAMEsKwfABLE  IaA  S($  Gl  S)S 

VALUEsNUMbER 

VALUEsTABNAME 

VALUtsOP 

value=cjnahe 

VALUEsXNAME 

VALUFsXFUNC 

VALUELISTsME 

VALUELISrsVALUELISf  $»S  ME 

VARsKMVAR  IAA 

VARrUVAR 

VARsSFREQS 

VARsINIPAR 

VARsST IMt» 

VARLSTrVARLari 
VARLSTsVARLST  S,S  VARLBTt 
VARLST I sVAR 
VARLSTl«CUNSTANr 
VARLSTIsTABNAmE 

VARSETs$(S  C51ST  S/S  GblSf  S)S 
MCSHsSmURSTcaSES  EULC 
WCSHsMCSH  VaRSET  EULC 
XFUNCsSFS  IAA  S(S  VARLST  S)S 
XNAMEsKNEXP  IaA  S(S  ME  S)S 
/END 
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APPENDIX  I 


CIRCUS-2  GRAMMAR 


This  appendix  lists  the  grammar  for  the  CIRCUS-2  language  using  BNF 
notation  which  is  consistent  with  the  input  to  the  LR(k)  Parser  Generator. 
A listing  of  the  undefined  terminal  symbols  and  their  corresponding 
character  strings  is  given  below: 


Lexical  Symbol 


Character  String 


ALPHASTRING 

AOP 

APOSTROPHE 

CHARGl 

CHOPTIONS 

COMPNAME 

DEVNAME 

DEVPAR 

ELPFX 

BOLC 

FORTRAN 

FSPFX 

lAA 

IAA2 

ILA 

INTEGER 

INTERVAL 

MFUNC 

MOP 

RCLPFX 

STRING 

ZYPFX 


A string  of  alphameric  characters 
+ or  - 

I 

I,  T,  or  * 

SHIFT  or  SCALE 

An  alphameric  identifier  beginning  with  a letter  with 
a maximum  of  four  characters , representing  a com- 
ponent name 

An  alphameric  identifier  with  a maximum  of  eight 
characters,  representing  a device  name 

A device  parameter  name 

R,  C,  L,  K,  V,  J,  PV,  PJ,  SV,  SJ,  TV,  TJ,  Z,  or  Y 
End  of  logical  card  symbol 

A block  of  FORTRAN  code,  including  the  END  statement 
V or  J 

An  alphameric  identifier 

An  identifier  containing  only  letters  with  a maximum 
of  two  characters,  representing  a model  label  prefix 

An  alphameric  identifier  beginning  with  a letter 

An  unsigned  integer 

PRINT  INTERVALS,  PLOT  INTERVALS,  or  RECORD  INTERVALS 
Any  mathematical  function  name 
* or  / 

R,  C,  or  L 

Any  character  string 

Z or  Y 
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The  complete  description  of  the  CIRCUS-2  grammar  is: 


/COMMENT 
/DEBUG  1 
/COMMENT 
/COMMENT 
/COMMENT 
/COMMENT 

/comment 

/COMMENT 


CIMCUS-2  grammar  7/22/75 

8 

RClPFXsR/L/C 

FSPFXsV/J 

ZYPFXbZ/Y 

INTERVAL*  PRINTINTERVALS/PLOTINTERVALS/RECOROINTERVALS 

CHARGI*  */i/i 

CHOPTIONSsShIFT/SCALE 


/LEXICAL 

SEnOUFJOBS  20 

EOLC  fl 

SENDS  21 

ILA  5 

i,%  11 

lAA  6 

SIS  12 

S)S  13 

S*S  14 

S*S  IS 

SCHANCES  22 

SCLOBALCHANGES  2i 

SDEVTCENAMES  24 

SMUOELNAMES  25 

SARRAYSS  2b 

SDEVICESS  27 

SENOUFINPUTS  28 

IAA2  7 

SEUUATIONSS  29 
SRESlARfS  30 
SEXECUTES  31 
SEXTERNALNOOESS  32 
FSPFX  33 
SFUNCTIONSS  34 
SGLOHALDEVICEPARAMETERSS  35 
SDIAGNOSTIC8S  36 
ShOLDFINALCONOI riONSS  37 
SSAVES  38 
SSIOPTIMES  39 
SINCREMENTSTOPTIHES  40 
SINITIALCUNDITIUNSS  41 
SLIHITSS  42 
SLS  43 
SMUDELSS  45 

SDEFaUL IOEVICEPARaMETERSS  46 
SFIXEOPARAMEIERSS  47 
SD.C.STEAOYSTATES  48 
SMULTIPLEEXECUTE»S  49 
INTEGER  8 
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SENUMUL  MHLEEXECUTE*  50 
NUMttEH  i 

SUPFIMUaTIONCRITERIUNS  bl 
SPKINTS  52 
SPLUrS  5^ 

SMECUROS  sa 

SSINGLEVALUEOPAHAMETERSS  55 
$JNE0rMENSIUNALTA8LES»  5t> 
stwooimensiunaltahless  5/ 
SPMEFIXJ  S9 

alphastring  3 
CHOPMONS  59 

RCLPFX  bO 

SREFERENCENUOEI  61 
SCARDLENGTHS  62 
SLISTS  63 
SNOLISTS  6a 
APOSrRUPHE  9 

string  to 

SPLOTPACELIMITS  6S 
SNOMODELLIURARYS  66 
SNODEVICELIBRaRYS  67 
SSS  66 

SSTEAOYSTaTEGUESSS  69 

ssteaoystateprints  70 
STS  71 

STOPOLOCYS  72 
2YPFX  73 
ELVOLT  7a 
FORTRAN  75 
SPS  76 
ELCURR  77 
ELNAmE  76 
DEVNAME  79 
NOGEVOLT  60 
COMPNAME  61 
DEVCLASS  82 
nUTFUNC  83 
INTERVAL  6U 
SOS  85 
OEVPAR  66 
CHARGl  87 
OEVPAKAM  88 
AUP  89 
MOP  90 
S**S  91 
MFUNC  92 
ELPFX  93 
/8NF 

GOALsGECK 

ARGLISTsILA 

ARGLISTsARGLIST  S,S  ila 

arrayulksaryblki  EOLC 
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ARRAYBLK  = ARt<ArBLK  AHYBLKl  EQLC 
ARYBLKIsIAA  S,S  AHYVAL 
ARYBLKlsAKYBLKl  %,%  A><YVAL 
ARYVALsVALUt 

ARYVAL=$(SVALUE  %,i  VALUE  S)S 
CMARGS  = CHAWG  I 
CHARGS=ChaRGS  S,S  CHAHGl 
CMC1RC=S*S  lAA  S=$  VALIST  EULC 
CHCIWCs$*s  tAA  *2*  VP  EOLC 
CHOEvrSCHANGES  S,S  CHPaIPS  EULC 

CBDEVPAWAMrtCHANGES  $,i  DEVICE  »,$  VPLiSr  EULC 
CHGLU8AL=»GL0BALCHANCE>  $,%  VPLIST  EULC 
CHNG=CHCIRC 

CHNG=CMDtV 
CHNG=CHDF VPARAM 
CHNG=CHGLUHAL 

CNPAlRlr$(SJLDNAMES,S  DEVNAME  S)$ 

CHPAIRS  = CHPA  IRl 
chpaihs=chpaihs  i,$  chpaihi 


DECKsKUN  SEROOFJQb*  EULC 
decksrun  serds  eolc  deck 

DEVBLKsSDEVICENAMES  S = $ IAA  S,%  SMLIDELNAMEJ  S*S  lAA  EOLC  DEVBLKl 
DEVBLK ISDEV8LK2 
DEVBLKl=OEV8LKl  DEVBLK2 
DEV8LK2SPAR8LK 

DEVBLK2s$ARRAYSS  EULC  ARRAYBLK 
DEVCLASS=IAA2  S,%  IAA 

device=devname 

device=oevclass 

DEVICEBLK=SDEVICES$  EULC  OEVBLK  SENDUFINPUTS  EULC 

DEvHEF=IAA2  IAA  S,$  NODELIST  S,$  DEVNaME  EULC 

DEVREF=IaA2  IAA  $,»  NUDELIST  EOLC 

ELCUHR=SIS  S.S  ELNAHE 

EL£M=RCL 

ELEMzK 

elemsfixedsuuhce 

ElEHsPSUUHCE 

ELEMsSINESUUHCE 

ELEMsTABSUUMCE 

EL£M=2Y 

ELNAMEsELPFX  IAA 

elname=elname  IAA 

ELVULTsIVS  S.S  ELNAHE 
EUN32SEUUATIUNSS  EULC  FORTRAN 
EXECI=EXEC1  A 
EXEC1*EXEC1  EXECIA 
EXEC  lAsGLUBALDP 
EXEClAsFUNCLiST 
EXEC  1 AsREFNUDE 
execiasoevref 

EXECIAsELEM 

EXEClAsDUr 

EXECIAsHSS 

EXEClAaQPT 
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EXEC |A=$«ESTAHrs  EULC 
EXEClAsGKPl 
EXECl A=SSPH1NT 
EXEC^sEXfcC«  EXECS 
EXEC2=EXEC^  ExECa  EXECS 
EXECSsMjlTEX 
EXECSsSEXECUTES  EULC 

exec«=execs 

EXEC«s£XEC«  EXECS 
EXECS=GHPl 
EXECSsLIMI T 
EXECSsCMNG 

EX1N00ES=*ExIEHNALN0UESS  4=$  S(S  NOOELIST  S)S  EULC 

F IXEOSUUHCEsPSPFX  lAA  S,S  NUDELIST  S*$  VALUEi  EULC 

FUNCsIAAS(SAHGLlST$)S  S=S  ME  EULC 

F UNCL ISTsSFUNC T lUNSS  EULC  FUNCS  SENDS  EOLC 

FUNCS=FUNC 

FUNCS=FUNCS  FUNC 

Gl0BALDP=SGl08Al0EVICEPA«AMETE«SS  EULC  PARBLUCK  SENDUFINPUTS  EULC 

GRPtsSDiACNUSriCSS  EULC 

GRPIsShOLDFINaLCUNOI TIUNSS  EULC 

GRPlsINCSI UP 

GRPlsINITCOND 

grpi=uut interval 

GRPlsSSAVES  EULC 
GRPUSS6UESS 

GRPlsSSTUPTIHES  SsS  NUMBER  EOLC 
ICLISTsICLISTA 
ICLISTzICLiST  S,S  ICLISTA 
ICLISTAsELVOLT  SsS  VaLUE 
ICLISTasELCURR  SsS  VaLUE 

INCSTUPsSINcREMENTSTOPTiMES  S,%  value*  EOLC 
iNircONOsSlNlriALCONDlTIUNSS  S«S  ICLIST  EULC^ 

INI rcUNOsSiNiTIALCONOl TIONSS  SsS  SOS  EULC 
KsSKS  lAA  S,S  LNAHE  S,S  LNAHE  S,S  VALUE  EOLC> 

LIMITsSLIMlTSS  SsS  INTEGER  EOLC 

LNAMEsSLS  IAA 

MEsAUP  MTERM 

he=mterm 

MEsHE  AOP  MTERM 

mfactor=mfacturi 

MFACTORsMF acturi  S**S  mfactdri 

MFACTUR|sS(S  me  S)S 

MFACTURIsNUMBER 

MFACTURtslLA 

MFACTORtsMFUNc  S(S  VaLUELIST  S)S 

MODBlksMDOEL 

MU08lK=MUDBlK  model 

MUDELsSMUOEL^iAMES  %»S  STRING  EOLC  MOOSECS  SENDUFINPUTS  EULC 
MOdELBLKsSMOOELSS  EULC  MODHLK  SENDUFINPUTS  EULC 
MODSECAsEQNS 

MUDSECA  sSDEFaULToEVICEPAHANETERSSEOLC  PARHLUCK 
MUDSECAsSFIXEOPaRaMETERSS  S>S  ARGLIST  EOLC 
MODSECAsSARHAVSS  S*S  ARCLIST  EOLC 
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M00SECS  = tXTN00E3  10»»0 
MOD8£CS*moOSECS  MQOStCA 

HSS=$D.C.STEAOrST A TEStULC  PAHVAHLIST  SENDS  E3LC 
MIEHMsHF ACT3W 
mtehmsmiehh  mop  MFACTOH 

mJLTeXsSMUlT IPLEEXECU»E»S  INTEGEW  EOLC  HXUL3CK  SENDHUL f [PLEEXECUTESEULC 
MXBLKsCHNCi 

MXBLKsINCSI DP 
MXHLUCKSMXBL.K 
MXBLOCKsMxBLUCK  HX8LK 
NDOE=I AA 
NUDEL ISTrNUOE 

NUOELISrsNOOEL 1ST  S«S  NUDE 
NJDEPEFsl AA 

NOOEHEFsNUOEPEF  »,» 

NUMLiSTsNUMdtR 
NJMLISTsNUMLlST  S,S  NUM.JFH 
ULONAMEsOE VNAME 
ULONaMEsCUMPNAME 

OPT=SUPTIMI/aTIONcPITER1I)NS  S = S (JUTVAR  eulc 
UUTsSPMINTS  S,S  UUTLIST  eolc 
UUTsSPLOTS  s»s  puutlist  eulc 
OUTSSKECUHDS  %,S  UUTlIST  EULC 
(JUTInTERVAlsINTERVAL  ».s  numlist  eulc 

OUTLISTsOUTVAR 

OUTl IST=UUTlIST  S,S  UUTvaR 

UUTPaIRSsV ARPAIR 

OUTPA [RS=UUTPA IRS  S*S  VARPAIR 

OUTVaR=ELVOLT 

UUTVAHsElCURH 

uurvAR=svNs  s.s  nuoeref 

UUrVARsOEVPAR.CONPNAME 

OUTVARsHFUNC  S(S  VALUELIST  S)S 

PARBLKsPARBLXZ 

PARBLKsPaRBLKI 

PARBLK=PARBLK2 

PARBLKZ=SSINGLEVALUEDPARAMETER3S  EOLC  PBLKZ  EULC 

PAHBLKtsSUNEDlHENSiUNALTABLESS  EOLC  PBLKl 

PARBLrazSTNOOIMENSlONALTABLESS  EULC  PBLK2 

PARBLUCXsPaRBLK 

PaRBLUCXsPaRULOCK  PARBLK 

PARVaRLISTsPVaRa  eolc 

PARVaRLIST*PARVaRLIST  pvaha  eulc 

PBLKZsPBLKZa 

P9lkZ»PBlkZ  S,S  PBlkZA 

PBlkZAsIAA  S*S  value 

PBLRlsPBLKlA 

PBLKIaPBLM  PBLKIA 

PBLKIAsIAA  l,»  S(S  VALIST  t)S  $,S  S(S  VALI3T  S)S  EULC 

P8LK2sPBLK2A 

PBLK2aPBLK2  PBLKZA 

PBLK2AZIAA  %,%  SIS  V AL 1 9 T S ) * ( SV AL 1 ST S) * ( SV AL I ST S ) S EOLC 
POUTLlSTaUUTLlST 
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POUTLlSTsOUtLIST  S*S  OUfPAIRS 

PREFXsPHEFXJ 

PREFXsPREFX  PHEFXl 

PREFXlsSPREFlXS  l,%  1AA^  %»%  ALPHASTRING  EULC 
PSUURCEsSPS  FSPFX  lAA  S.S  NUOELlST  $,%  VALIST  EULC 

pvaraspvarh 

PVARASPVAKA  S,$  PVARH 
PVARHsElNAhE  S=S  S(S  VALlSr  S)S 
PVARRsDEVPAR  S^S  SCS  VALIST  S)S 
PVARHsOEVPaR  SsS  CHOPTIUnS  S=S  S(SVALISTS)$ 
RCLaRCLPFX  (AA  »»8  NUUELIST  %,%  VALUE  EULC 
REFNUyEsJREFERENCENUOES  $sS  NODE  EULC 
RUNsRUnGRP 


run^kun  kunqrp 

/CUMMtNT  FULLUNING  rungrp  pruouctions  may  uccur  arbitrarily  in  input 
RUNGRPsSCARDLENGTHS  S=S  integer  EULC 
RUNGHP=$LISTS  EULC 
RUNGRPaSNULlSTS  EULC 

/CUMMENT  FOlLUWING  RUNGRP  PRQUUCTIUNS  MAY  UCCUR  ARBITRARILY,  BUT  NUT 
/CUMMtNT  INSIOE  MUOELBLK 
RUNGRP=APUSTRUPHt  STRING  EULC 
RUNGHP=SPLUTPAGELIMITS  S=$  INTEGER  EULC 

/CUMMtNT  FUlLURING  RUNGrP  PRUOUCTIUNS  UCCUR  IN  GIVEN  UROER  MHfN  USED 
RUNGRP=LIM1 1 

RUNGRP=SNUHU0ELL18RARY$  EULC 

RUNCRPsSNOOEVICELIHRaRYS  EULC 

RUNGRPsMUOELBLK 

RUNGRP=0EVICEBLK 

RUNGRPspRtFX 

RUNGRPsEXECl  EXECi 

RUNCRPsEXECa 

3INESUuRCt=8SS  FSPFX  lAA  S.S  NUOELIST  S.S  VALIST  EULC 
SSGUESSsSSTeaoYSTaTEGUESSS  S.S  ICLIST  EULC 
SSPRINTsSSTeaDTSTaTEPRINTS  S.S  OUTLIST  EULC 

Tab3UURCE=STSFSPFX  IAAS.SNUDLLISTS.S  S(SVALISTS)S  S.S  S(SVALlSTS)SbULC 
TOPQ=STUPULOr,YS  EULC  TUPltLIST 
TUPUCAROalAA  l.S  NUUt  S.S  NUDE  EULC 
TUPULISTaTOPiJCARD 


TUPOLISTsTUPOLlST  TUPUCARO 
VALFUNCzIAA  S(S  CHARGS  S)S 
VALlSTsVALUE 
VALISTsVALIST  S.S  VALUE 
VALUEsNUMBER 
VALUELlSTzME 

valuelistzvaluelist  s*s  me 

VARPAlRzS(S  OUTVAR  S.S  UUTVAR  S)S 

VPsVALFUNC 

VPsVALUE 

VPsCHOPTIUNS  SzS  VALFUNC 
VP«S(S  VALIST  S).(S  VALIST  SIS 
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VPLlSTaVPLISTA 
VPLISTsVPLIST  S,S  VPlISTa 
VPLISTAalAA  SsS  VP 

VPLISTAsIAA  AsS  CNOPrlDNS  S>S  VALUC 

ZVa^YPPX  IaA  S»S  NUOCLIST  $»S  VALUE  S,S  $(S  VAL1STS),(S  VALlST  S)S  EULC 

/end 

■ ■ 
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APPENDIX  J 


DESCRIPTION  OF  THE  PARSER  FOR  THE  LR(k)  PARSER  GENERATOR 


This  appendix  lists  the  BNF  input  to  the  LR(k)  Parser  Generator 
which  produces  the  LR(k)  parsing  tables  for  the  LR(k)  Parser  Generator. 
The  input  listing  constitutes  a complete  description  of  the  grammar  for 
the  LR(k)  Parser  Generator,  including  identification  of  all  terminal 
symbols  and  their  lexical  codes.  Also  Included  is  specification  of 
semantic  routine  linkages  and  error  recovery.  The  intrinsic  grammar 
is  LR{1)  and  can  be  represented  by  37  read  states,  38  apply  states, 
and  6 lookahead  states. 

A listing  of  the  terminal  symbols  and  the  character  strings  which 
they  represent  is  given  below: 


Lexical  Symbol 


Character  String 


COMMA 

DYNAMIC 

EOLC 

EQ 

I 

LP 

NSHMANT 

RP 

SBNF 

SCOMMENT 

SDEBUG 

SEND 

SLASH 

SLEXICAL 

STAR 

STRING 

TSTRING 


D. 

End  of  logical  card  symbol 

Any  identifier  containing  edphameric  characters, 
starting  with  a letter 

( 

NSEMANT 

) 

BNF 

COMMENT 

DEBUG 

END 

/ 

LEXICAL 

« 

Any  character  string  enclosed  by  $ symbols 
Any  character  string  enclosed  by  $ symbols 
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The  lexical  analyzer  description  for  the  LR(k)  Parser  Generator 
is  given  in  Appendix  K.  The  complete  description  of  the  parser  for  the 
LR(k)  Parser  Generator  is; 


/comment  sgrammak  for  parser  and  sot  generators 
/lexical  I 

INTEGER  2 
EOLC  4 
SLASH  14 
LP  IS 
HP  16 
EQ  17 

SLEXICAL  20 
SBNF  21 

send  22 

SOEBUG  2i 
SCUMMENT  24 
COMMA  2S 
NSEMANT  27 

/lexical  2 

I 1 

INTEGER  2 
EOLC  4 
SLASH  14 
LP  IS 
star  is 

COMMA  2S 
/LEXICAL  3 
string  3 
/LEXICAL  4 
I 1 

integer  2 

EOLC  4 
slash  14 
LP  15 
COMMA  2S 
TSTRING  26 
DYNAMIC  ?S 
/8NF 

8(7)sSl  BNFt  ENOl 
S(7)sBnF1  ENOl 
S13S2 

Sic3i  32 

S2( IB)s(EULC)  SLASH  NSEMANT  INTEGER  EOLC  * 

S2SLEX1 

S2SCOMM 

LEXl  (6)s(E()LC)  SLASH  SLEXICAL  INTEGER  EOLC'  * 
LEXla(EOLC)  SLiXSH  SLEXICAL  EOLC  • 
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LEXlsLEXl  lex 

BNFls(EULC)  SLASH  SBNF  EQLC  • BNFA 
BNFIsBNFI  BNFA 
BNFAs(ErJLC)  BNFi  EOLC  • 

BNFAsCOMM 

BNF2SBNFDEF 


BNF2sBNF2  CUHMA  SOT 

bnfoef(5)=class  code  EQ 
BNFOEF(S)sCLA33  tO  OEF 
CLASS(2)sl 

C130E(3)=LP  (RP)  integer 


OEF 


RP  * 


OEFsTERM 
OEFsoEF  TERM 
TERM(a)s| 

TERM( 10)=LP  (RP)  I RP  * 

TERH(21)=LP  integer  RP 
TERHdl  )sSTAR 

LEX(6)s(E»LC)  1 INTEGER  EOLC  * 

SOTsSOTl 

SOTsSOT  SOTTERH 

SOTlsSOTTERH 

SOrisTRANS  EO  SOTTERH 

SDTTERH(19)sI 

SOTTERH( I2)*I  LP  (RP)  INDEX  RP  * 
S0TTERN( 13)bTSTRING 
SDTTERM(20)aOVNAHIC  INTEGER 
TRANS(  I<I)sINTE6ER 
INDEXT lS)sINTEGER 
INOEX( lb)rC0HHA  INTEGER 
1NOEX(17)sINTEGER  COMMA  INTEGER 

commsslash  scumhent  string 

COMMr(EOLC)  SLASH  SOEBUG  INTLIST  EULC 
INTLIST(9)sINTEGER 

intlist(9)sintlist  integer 

ENDIs(EOLC)  slash  send  EULC  * 

ZENO 
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APPENDIX  K 


DESCRIPTION  OF  THE  LEXICAL  ANALYZER  FOR  THE  LR(k)  PARSER  GENERATOR 


This  appendix  lists  the  input  to  the  Lexical  Analyzer  Generator  which 
produces  the  lexical  analyzer  tables  for  the  LR(k)  Parser  Generator.  The 
description  of  the  lexical  analyzer  is: 


/CUMHtNf  LEXICAL  ANALYZER  FOR  PARSER  AND  SOT  GENERATOR 

/HAXSCAN  4 

/WORKSPACE  2 

/HAShTABLE  751 

/IOTABLE  2000 

/CHARTABLE  49 

/CHARCOOE 

A 1 

B 2 

C 3 

0 4 
E 5 
F 6 
C 7 
H 8 

1 9 
J 10 
K 11 
L 12 
N 13 
N 14 
0 15 
P 16 
Q 17 
R 18 
S 19 
T 20 
U 21 

V 22 
W 23 
X 24 

Y 25 
Z 26 


DO 

27 

01 

28 

02 

29 

03 

30 

04 

31 

05 

32 

210 


Ob  S3 

07  3« 

08  35 

09  3b 
PLUS  37 
MINUS  58 
STAW  39 
SLASH  aO 
LP  ai 

PP  a? 

OULLAH  as 
EQ  94 
BLANK  45 
comma  4b 
our  47 
EULC  48 
NUCARO  49 
/LEXCUDE 
INTEGER  ^ 
string  3 

EULC  4 

SLASH  14 
LP  15 
RP  16 
EU  17 
STAR  IS 

lexical  ao 

BNF  21 
ENO  22 
OEBUG  23 
COMMENT  24 
COMMA  25 
TSTRING  26 
NSEMANT  27 
OYNAHIC  2B 

/Scanner  1 

/CLASS 

38C0EILMHST 
5 EULC  SLASH  LR  RP  EQ  COMMA 
7 blank 

a 00  01  02  03  04  05  06  07  Ob  09 

9ABC0EF  GHIJKLMNOPORSTUVMXYZ 

/KEYHUROS 

LEXICAL 

BNF 

ENO 

OEBUG 

COMMENT 

NSEMANT 

/FSA 

Sl»EULC*EULCrS2 

S2#SLASM»SLASH*S3 

S3,LP»LP»S4 
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54, RP,KP,S5 
SS>EQ*EU»  Sb 
S6.CUMMA,CUMMA» 1 
/SCANNER  2 
/IDENTIFIER  I 
/CLASS 

aAHCDEFGHlJKLNNOPQKSrUVMXYZ 
5 SLASH  EULC  COMMA 
5 LP  STAR 

7 blank 

8 DOLLAR 

8 00  Ot  0^  D3  Da  OS  Ob  07  06  OR 

‘TABCDEFGHIJKLMNOPtJRSTUVMXYZ 

9 00  01  Oa  05  04  05  Ob  07  08  09 
/F3A 

llrCtlMMA, COMMA, 

S2, SLASH, SLASH, S5 
S3,EULC,E0LC»  S4 
S4, STAR, star, S5 

55, LP,LP»1 
/SCANNER  5 
/CLASS 

SABCDEFGHIJKLMNOPORST’JVHXYZ 
5 00  Dl  02  05  04  05  Ob  07  08  09 

5 PLUS  MINUS  STAR  SLASH  LP  RP  DOLLAR  E<J  BLANK  COMMA  DOT 
/FSA 

S1,5,A1,S2 

$2,EULC,STR1NU,  1 

/scanner  4 

/IDENTIFIER  I 
/CLASS 

4ABCEFGHIJKLHN0P0RSTUVNXYZ 
5 comma  LP  EOLC  0 

7 BLANK 

8 DOLLAR 

8 DO  01  0?  05  04  05  Ob  07  06  09 

9ABC0EFCHIJKLMN0PQRSTUVNXYZ 

9 DO  01  02  03  04  OS  Ob  07  08  09 
/FSA 

51,  COMMA, COMMA, S2 

52, E0LC*EULC*S5 
S5,LP,LP»S4 
S4,0,S5, 1 

S5, our, dynamic, 4 
/END 

• m 
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APPENDIX  L 
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DESCRIPTION  OF  THE  PARSER  FOR  THE  LEXICAL  ANALYZER  GENERATOR 

This  appendix  lists  the  BNF  input  to  the  LR(k)  Parser  Generator  which 
produces  the  LR(k)  parsing  tables  for  the  Lexical  Analyzer  Generator,  The 
input  listing  constitutes  a complete  description  of  the  grammar  for  the 
Lexical  Analyzer  Generator,  including  identification  of  all  terminal 
symbols  and  their  lexical  codes.  Also  included  is  specification  of  semantic 
routine  linkages  and  error  recovery.  The  intrinsic  grammar  is  LR(2)  and 
can  be  represented  by  60  read  states,  hj  apply  states,  and  8 lookahead 
states . 

A listing  of  the  terminal  symbols  and  the  character  strings  which 
they  represent  is  given  below: 

Lexical  Symbol  Character  String 

EOLC  End  of  logical  card  symbol 

I Any  alphameric  identifier,  beginning  with  a letter 

IDENT  IDENTIFIER 

INTEGER  An  unsigned  integer 

STRING  Any  character  string  enclosed  by  $ symbols 

The  lexical  analyzer  description  for  the  Lexical  Analyzer  Generator 
is  given  in  Appendix  M.  The  complete  description  of  the  parser  for  the 
Lexical  Analyzer  Generator  is: 


/conhent  scrammar  for  parser  fur  lexical  analyzer  generators 

/LEXICAL  1 

INTEGER  2 

EOLC  a 

S/S  14 

ifS  IS 

S*S  16 

SSSS  17 

SMORKSPACES  19 
SHASHTAttLES  20 
SIOTaBLES  21 

sends  22 

SCHARTABLES  23 
SCHAHCUOES  24 


213 


W 


SLCXCOOES  25 
SSCANNERS  2b 
SCLASSS  26 
SKEYWUHOSS  2R 
SKNLENGfMS  50 
SFSAS  51 
SDEHUGS  32 
SMAXSCANi  53 
SCCJMMENTS  34 
lOENT  5b 
iLS  57 
/LEXICAL  2 
I 1 

INTEGER  2 
ECJLC  4 
S/S  14 

S,S  IS 
S*S  lb 
SSSS  1/ 

/LEXICAL  3 
string  3S 
/BNF 

S(2b)sGLnBALl  GLOBAL2  SCAN  ENOI 
GLOBAL  I ( lOlsGLUBAL 
GLOBALsGLB 
GLOBAL=GLUBAL  GLB 

GLB(2)s(FULC)  S/S  SWORKSPACES  INTEGER  EOLC 
GLB(3)  = (E()LC)S/S  SHASMTABLES  INTEGER  EOLC 
GlB(4)=(EOLC)  S/S  SIUTABLES  integer  EOLC  • 
GLB(S)=(EULC ) S/S  SCHARTAHLES  INTEGER  EOLC 
GLBs(EOLC)  S/S  SCMARCUDES  EOLC  * CHRCUB 
GLB(24)s(E(JLC  ) S/S  SMAXSCANS  INTEGER  EOLC 
GLBsCUMN 

GLOBAL2r(ED.C)  S/S  SLEXCODES  EOLC  * LEX 
CHRC00(6)a(E0LC)  I INTEGER  EOLC* 
CHRCOD(b)=(EOLC)  CHWCUO  I INTEGER  EULC* 
LEXsLEXI 
LEXsLEX  LEXl 

UEXI(7)s(EULC)  I integer  EOLC  * 
LEXi(13)s(EOLC)  I EOLC  * 

LEXl  (9)a(E0LC)  I INTEGER  LEX2  EOLC  * 
LEX2(2B)=INTECER 

LEX2(29)=LEX2  SLS  INTEGER  INTEGER 

SCANsSCANI 

SCANsSCAN  SCANl 

SCANl (B)=(E0LC)  s/s  SSCANNERS  INTEGER  EOLC 

SCANlsSCANl  SCAN2 
SCAN2sSCANCLS 
SCAN23SCANKM 
SCAN2( 15)sSCANKWL 
SCAN2(25)3SCAnFSA 


SCANasCUHH 

SCAN2(27)s(EOLC)  S/»  IDENT  InTECEH  EULC  * 

3CANCLSs(E0lC ) S/1  SCLASSS  EOLC  * CLASSl 
SCANCLSsSCANCLS  CLASSl 
CLASSlsCfcOLC)  CLAS3NO  lOLlST  ECJLC  * 

CLASSN0(  1 1 )sINTEc,ER 
IOLISK  J2)  = l 
IDLIST(1^)=I0LI3T  I 

SCANKW=(EULC)  s/s  SKEYWORDSS  EULC  * LEX 
SCANKWLs(EULC)  S/S  Sk*<LENGTH$  INTLIST  EULC  • 

INTLI3T( i«)=integer 
INTUIST(1<J)=INTLIST  integer 
3CANFSA=(F UlC)  S/S  SFSAS  EDLC  * F3A1 
SCANFSA=SCAnF3A  FSAl 

FSAl  (22)  = (E'JLC  )SSSS  INTEGER  S/S  SYMbUL  S,S  DE3T  S#S  OEST  EULC  * 

SVMb[)L(  I6)sl 

SYMBDK  J7)sINTEGER 

OEST( 18)=SSSS  INTEGER 

DEST( 19)=I 

OEST (20 )=INT£GEH 

DEST(2l)=»*$  INTEGER 

CJMM=S/S  SCUMmENTS  STRING 

COMM=(EOLC)  S/S  SOEBUGS  DLIST  EOLC  * 

OLlST(25)=INrEGER 
DLIST(2S)=0LIST  INTEGER 
END1=(E0LC)  S/S  SENDS  EOLC  » 

/END 
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DESCRIPTION  OF  THE  LEXICAL  ANALYZER  FOR  THE  LEXICAL  ANALYZER  GENERATOR 


This  appendix  lists  the  input  to  the  Lexical  Analyzer  Generator  which 
produces  the  lexical  analyzer  tables  for  the  Lexical  Analyzer  Generator. 

The  description  of  the  lexical  analyzer  is; 

/COHMENT  DEbCHIPriON  UF  lexical  analyzes  fur  lexical  analyzer  GENERATUH 

/NAXSCAN  i 
/WORKSPACE  ^ 

/MASHfAflLE  751 
/IOTABLE  ^000 
/CHARTA8LE  <l9 
/CHARCUOE 
A 1 
B 2 
C 3 
D a 
E 5 
F b 
G 7 
H H 
I 9 
J 10 
K 11 
L 1«? 

M IS 
N 14 
0 15 
P lb 
Q 17 
R IS 
3 19 
T 20 
U 21 

V 22 
N 23 
X 24 

Y 25 
Z 2b 


DO 

2/ 

D1 

2S 

02 

29 

03 

30 

04 

31 

05 

32 

Ob 

33 

07 

34 
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D8  iS 
D9  56 
PLUS  37 
MINUS  5tt 
STAR  39 
SLASH  ao 
LP  41 
RP 

DULLAR  43 
EQ  44 
BLANK  4b 
COMMA  46 
OUT  47 
EULC  48 
NOCARD  49 
/LEXCUOE 
SLASH  14 
WORKSPACE  19 
INTEGER  ^ 
EULC  4 


HASHTABLE  ^0 
IOTaBLE  21 
CHAHTABLE  23 
CMARCOUE  24 
LEXCUDE  2S 

scanner  26 

CLASS  28 
KEYWORDS  29 
KWLENGTH  30 
FSA  31 
DOLLAR  17 
COMMA  15 
STAR  16 
END  22 
DEBUG  32 
HAXSCAN  33 
COMMENT  34 
string  3S 
identifier  36 
L 37 

/SCANNER  1 
/CLASS 

1 ABGJOPORUVXy 
3CDEFHIKLMN3T 
5 SLASH  EOLC  DOLLAR  COMMA 

7 BLANK 

8 DO  01  02  03  D4  Db  06  07 
9A8C0EFCHIJKL 
/KEYWORDS 

WORKSPACE 

HASHTABLE 

IOTABLE 

chartaule 


Z PLUS  MINUS  LP  RP  CU  DOT 
w 

STAR 
D8  09 

MNOPORSTUVWXYZ 
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CHARCUDE 

lexcdoe 

SCANNER 
CLASS 
KE VHOHDS 

kwlenuth 

FSA 

END 

DEBUG 

NAXSCAN 

CUMME.N  r 

IDENTIFIER 

L 

/FSA 

SI t slash«  slashes? 

$2»EOLC»EnLC»S3 
S3»D()LLAR,DULLAK,  SR 

SR,  COMMA, CUMMAySS 

SS,  STAR, star, I 
/SCANNER  i 
/IDENTIFIER  I 
/CLASS 

RABCOEFGHIJKLMNOHQRSTUVMxr/ 

R PLUS  MINUS  LP  RP  ti4  DOT 
S SLASH  tULC  DOLLAR  COMMA  STAR 
7 blank 

S DO  Dt  0^  03  OR  OS  Ob  07  06  DR 

9ABCDEFGHIJKLMNUP0RSTUVNXYZ 
9 00  Dt  0^  Oi  OR  05  06  07  08  09 
9 PLUS  MINUS  LP  «P  EQ  OUT 
9 SLASH  dollar  STAR 
/FSA 

SI, SLASH, SLASH, SZ 
SZ,E0LC#EnLC*S3 
S3, DOLLAR, DOLLAR, SR 

SR,  COMMA, COMMA, S5 

SS,  STAR, star, 1 
/SCANNER  3 
/CLASS 

SABCOEFCMIJKI  MNOPORSlUVMXrZ 
S 00  01  0^  03  OR  Ob  07  08  09 

5 PuL'S  MINL'G  aUR  SLASH  LP  RP  DOLLAR  EQ  BLANK  COMMA  DOT 
/FSA 

SI, 5, SI, S? 

Sa,EULC, STRING# 1 

/end 
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APPENDIX  N 


EXECUTIVE  CONTROL  LANGUAGE  GRAMMAR 


This  appendix  lists  the  grammar  for  the  Executive  Control  Language 
using  BNF  notation  which  is  consistent  with  the  input  to  the  LR(k)  Parser 
Generator.  The  grammar  is  LR(1)  and  the  parser  generated  by  the  grammar 
has  71  read  states,  55  apply  states,  and  11  lookahead  states. 

A listing  of  the  terminal  symbols  and  the  character  strings  which  they 
represent  is  given  below; 


Lexical  Symbol 


Character  String 


AND 

AOP 

CCARD 

CHRSTRNG 

COMMENT 

EOLC 

ILA 

LABEL 

MOP 

NOT 

NUMBER 

OR 

PROCNAME 

RELOP 


.AND. 

+ or  - 

An  arbitrary  control  card  image 
Any  arbitrary  character  string 
An  arbitrary  comment,  ending  with  EOLC 
End  of  logical  card  symbol 

Alphameric  identifier,  starting  with  a letter 
An  unsigned  nonzero  integer  of  one  to  five  digits 
* or  / 

.NOT. 

A real  number  representation 

.OR. 

A procedure  name 

.EQ. , .NE.,  .LE.,  .LT.,  .GE.,  or  .GT. 


The  grammar  for  ECL  is: 


/CUHHENT  GRAMMAR  FOR  EXECUTIVE  CONTROL  LANGUAGE 

/lexical 

AND  I 
AOP  2 
SCALLS  3 
sees  a 

CCARD  5 
CHRSTRNG  b 
COMMENT  7 
SCONTINUES  R 
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$OEFINEt  9 
SOELETES  10 
SENDS  11 
SENOCCS  li 
EULC  13 
SGOTnS  14 
SIFS  15 
ILA  lb 
LABEL  17 
SLISTS  IR 
MUP  19 
NUT  20 

number 

UR  22 

PRUCNAME  23 
SREAUS  ^4 
HELUP  25 
SRETURNS  2b 
SSTuhLS  27 
SMRITES  2B 
S«S  29 
S(S  30 
S)S  51 
S/S  32 
S**S  33 
SSSS  34 
S*S  55 
/BNF 

ECLsECLCAROS  ECLENO 

ECLsPRUCStC  PRUCEND  ECLCAROS  ECLENO 

ECLsPHUCSEC  PHUCENO  ECLENO 

ARGxSTRINC 

ARGsmE 

ARGIsILA 

ARCIxNUMBER 

ARGLIBTsARCLIST  s,s  arg 
ARGLISTzAKG 
BEXPsOEXP  UR  BTERH 
BEXPsUTERM 
BFACTURsnOT  BFACTUR 
BFACTUR>S(S  BEXP  S)S 
BFACTUHsME  WELOP  ME 
BTEHHsBTERM  and  bfactok 
BTERMsbEACTUR 
CCLlSTsCCARD  EOLC 
CCLlSTsCCLIST  CCARU  EULC 

CCSECTxS/S  secs  S/S  EULC  CCLIST  S/S  SENOCCS  S/S  EOLC 

eclcarosxeclcaros  entry 

ECLCAROSsENTRY 
ECLENUsSENOS  EULC 
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ENTHYcLABEL  IFCLAUSE  STATEMENT  EULC 

ENTRYsLABEL  statement  EULC 

EMTHYsIFCLAUSE  statement  EULC 

ENTMYsSTaTEMENT  EOLC 

ENTNYsCCSF.CT 

ENTKYsCUMMENT 

IfCLAUSEsSlf S S(S  BEXM  S)S 

MEsAOM  MTERM 

HEsMTENM 

MEsHE  aOP  MTEMM 

mfactursmeactori 

nfactorshfactohi  S**$  mFACTUHI 

hFactorisargi 

MFACTURlsSCS  ME  S)S 

mteRmsmtemm  hop  mfactuh 

MTENHsHFACTOW 

PARAMxILA 

PARAMsSSSS  ILA  SSSS 

PARLSTsPAKLST  S«S  PARAM 
PARLSTsPARAM 
PROCCUMsSLISTS  EUlC 
PRUCCUMsSOEFINES  %,S  PROCDEF 
PROCCOMsSSTuRES  i,%  PRUCDtF 
PROCCOMsSUELETES  S»*  PKOCNAME  EOLC 
PRUCOEFxPROCHQW  EOLC  ECLCARUS  ECLEND 
PRDCENOsSENDS  PRUCNAME  EULC 
PROCHDRsPROCNAME  $(S  PAHLST  S)S 
PRUCHORsPRUCNAHE 
PRfJCREFsPKUCNAME 

PROCREFsPROCNAHE  S(»  AHCLIST  S)S 
PROCSECsPROcSEC  PRUCCUM 

PRUCSECsPRUCCUM 
REPLACEsILA  ME 

replacexila  sss  string 

ST ATEHLnTsSCUNTINUES 
STATEMENTsSCUTUS  label 
STaTEMENTsSRETURNS 
STaTEMENTxREPLACE 
STaTEMENTsICALLS  prucref 
STATEMENTsSNHITES  S($  VALLIST  S)S 
STATEMENTsSREADS 
STR1nC=SSS$  CHRSTRNG  SSSS 
VALLISTsILA 

VALLISTsVaLLIST  S,S  ILA 
/END 
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APPENDIX  0 


STRUCTURED  PROGRAMMING  CONVENTIONS 

The  programming  of  the  software  described  in  this  report  has  been 
accomplished  using  structured  programming  techniques.  This  has  been  done 
in  spite  of  the  fact  that  the  programs  are  written  in  FORTRAN  IV,  perhaps 
one  of  the  most  unsuitable  languages  in  general  use  with  which  to  use 
structured  programming.  The  structure  conventions  are  explained  below. 

These  conventions  are  used  in  both  the  actual  software  itself  and  in 
algorithms  which  are  given  in  this  report.  The  use  of  this  structuring 
method  eliminates  the  need  for  all  flow  charts  and  provides  a self  documenting 
capability  for  the  software  itself. 

Four  types  of  control  structures  are  used;  namely,  sequential,  DO  WHILE, 
IF-THEN-ELSE , and  CASE  control  structures.  By  suitable  combination  of  these 
four  types  programs  and  algorithms  of  any  complexity  may  be  written.  These 
basic  structures  are  combined  with  an  indentation  notation  which  is  used  to 
delineate  the  bounds  of  each  structure  in  the  program  or  algorithm. 

Since  FORTRAN  does  not  permit  the  keywords  DO  WHILE,  IF-THEN-ELSE,  and 
CASE  to  be  used,  these  keywords  are  written  as  structure  comments.  This 
permits  the  predicates  for  DO  WHILE,  IF-THEN,  and  CASE  to  be  written  in 
more  natural  terms  since  they  do  not  have  to  be  intelligible  to  the  compiler. 
They  are  followed  immediately  in  the  code  by  the  FORTRAN  implementation  of 
the  structure  comment.  Thus,  the  programmer  has  the  ability  to  write  programs 
in  true  structured  style  using  language  elements  of  his  own  choosing,  along 
with  the  implementation  of  the  structure  using  the  FORTRAN  language.  Thus, 
coding  and  documentation  are  carried  along  in  one-to-one  correspondence. 

In  addition,  all  algorithms  and  programs  were  developed  in  a topdown 
fashion  using  successive  redefinition.  Program  implementation  in  code  was 
not  begun  until  entire  major  sections  had  been  completely  written  in 
structured  comment  form.  Experience  with  this  technique  has  shown  that 
several  programs  can  be  simultaneously  implemented,  errors  are  greatly 
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reduced,  and  program  complexity  can  be  extended  by  an  order  of  magnitude 
with  no  loss  of  intellectual  manageability  compared  to  programs  written 
using  former  program  development  techniques. 

In  the  structured  comment  format,  each  comment  is  begun  with  an  asterisk 
to  visually  delineate  comment  lines  from  coding  lines.  A comment  may  be 
continued  on  the  next  line;  however,  the  next  line  does  not  have  the  asterisk 
header  and  starts  one  column  farther  in  than  the  first  line.  Thus,  if,  for 
a given  indentation  level,  the  comment  asterisk  appears  in  colimin  n,  the 
first  character  of  the  comment  continuation  will  start  in  column  n + 1. 

All  FORTRAN  statements  also  start  at  column  n + 1;  if  a FORTRAN  statement 
is  continued,  all  continuation  cards  start  at  column  n + 2.  Thus,  the 
structured  skeleton  is  easily  followed  by  the  identifying  asterisks  which 
introduce  the  structured  comments.  This  same  convention  will  be  used  in 
specifying  algorithms  in  this  report,  except  that  they  will  not  include 
any  FORTRAN  coding.  Each  subsequent  indentation  level  is  started  three 
columns  farther  to  the  right  from  the  previous  level  to  indicate  nested 
structures . 

Sequential  blocks  are  written  on  the  same  indentation  level  as  in  this 
example : 

» INITIALIZE  CONTROL  VARIABLES 
•READ  INPUT  DATA 
•BUILD  DATA  STRUCTURE 

•TRAVERSE  DATA  STRUCTURE,  GENERATING  OUTPUT 

The  IF-THEN-ELSE  structure  is  illustrated  by: 

•IF ( predicate )THEN 
•BLOCK  1 
•ELSE 

•BLOCK  2 
•BLOCK  3 
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If  the  predicate  is  satisfied,  then  BLOCK  1 is  executed.  BLOCK  1 is 
automatically  terminated  by  the  appearance  of  the  ELSE  on  the  same  level 
as  the  IF-THEN.  Thus,  following  the  completion  of  BLOCK  1,  control  is 
passed  to  BLOCK  3 (which  is  actually  a sequential  block  following  the 
IF-THEN-ELSE  block).  If  the  predicate  is  not  satisfied,  then  BLOCK  2 is 
executed,  followed  by  BLOCK  3.  An  alternate  form  of  the  IF-THEN-ELSE 
structure  occurs  when  there  is  no  EXSE  part: 

•IF( predicate )THEN 
•BLOCK  1 
•BLOCK  3 

If  the  predicate  is  satisfied,  then  BLOCK  1 is  executed,  followed  by 
BLOCK  3.  If  the  predicate  is  not  satisfied,  BLOCK  1 is  not  executed,  and 
control  passes  immediately  to  the  execution  of  BLOCK  3. 

The  DO  V/HILE  structure  has  the  form: 

•DO  WHILE ( predicate ) 

•BLOCK  1 
•BLOCK  2 

Here  the  predicate  is  tested  immediately  upon  entry  to  the  stricture.  If 
the  predicate  is  satisfied,  then  BLOCK  1 is  executed,  followed  by  a return 
to  the  predicate  test.  BLOCK  1 is  repetitively  executed  until  the  predicate 
is  no  longer  satisfied,  at  which  time  control  passes  to  BLOCK  2.  Note  that 
if  the  predicate  is  not  satisfied  the  first  time,  then  BLOCK  1 is  not 
executed  at  all.  A varisuit  of  the  DO  WHILE  is  the  DO,  sometimes  a more 
natural  meems  of  expressing  the  conditions  for  executing  the  subordinate 
block.  Its  action  is  identical  to  the  DO  WHILE: 

•DO ( predicate ) 

•BLOCK  1 


•BLOCK  2 


The  last  type  of  control  structure  is  the  CASE  structui’e.  This  is 
used  to  select  one  of  several  possible  blocks,  depending  upon  the  value 
of  an  expression.  Its  structure  can  be  seen  by  the  following  example: 

•CASE (expression) 

•Expression  value  = 1 
•BLOCK  1 

•Expression  value  = 2 
•BLOCK  2 


•Expression  value  = n 
•BLOCK  n 
•BLOCK  A 

The  expression  is  evaluated  and  control  is  passed  to  a particular  block, 
depending  upon  the  expression  value.  Following  completion  of  the  specified 
block,  control  is  passed  out  of  the  CASE  structure  to  the  next  sequential 
block,  BLOCK  A. 

Combining  these  ideas  permits  us  to  write  algorithms  of  any  complexity. 

As  an  example , consider  the  following  algorithm  for  traversing  an  n-ary 
tree,  where  each  node  of  the  tree  is  represented  by  a linked  list  of  sibling 
cells,  each  of  which  has  a pointer  to  a descendant  node.  Thus,  each  sibling 
cell  has  two  pointers,  one  for  the  next  sibling  cell  and  one  for  the  descendant 
node. 


TRAVERSE  N-ARY  TREE  ALGORITHM 


•ENTER  ROOT  NODE 
•TRAVERSE=TRUE 
»BACKUP=FALSE 
•DO  WHILE (TRAVERSE) 

•IF (NODE  CELL  HAS  DESCENDANT  AND  BACKUP=FALSE)THEN 
•DESCEND  TO  DESCENDANT  CELL 
•ELSE 

•IF(N0DE  CELL  HAS  SIBLING  CELL)THEN 
•MOVE  TO  SIBLING  CELL 
•BACKUP=FALSE 
•ELSE 

•BACKUP  TO  PARENT  CELL 
•IF (ROOT  NODE)THEN 
•TRAVERSE=FALSE 
•BACKUP=TRUE 

•STOP 

Frequently,  the  STOP  step  is  implied;  that  is,  when  the  algorithm  drops 
off  the  end  it  is  considered  to  be  finished. 
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Honeywell,  Incorporated 

Government  & Aeronautical  Products  Division 
ATTN:  Ronald  R.  Johnson,  A- 1622 

Honeywell,  Irn'orporaled 

Aerospace  Division 

AriN:  SUeey  M.  Graff,  M S.  725-J 
ATTN;  Jam«*s  I).  Alien,  M S.  77.5-D 
ATTN:  HarriMon  H S*oh| -,  M.S.  725-5A 

Honeywell,  Inc*orporaU*d 
A'lTN:  TiH-h.  Lib. 

Hughes  Aircraft  Company 

ATTN-  hilly  W.  Camp)*-ll,  M.S.  6-E-llO 
ATTN:  Ki-nnelh  R Walker.  M.S.  D-157 

Hughes  Aircraft  Company 

Space  Systems  Division 

ATTN:  William  W.  Scott,  M.S.  A-IORO 
ATTN:  Edward  C.  Smith,  M.S.  A-620 

IBM  Corporation 

ATTN;  Frank  Frankovsky 

ATTN;  Harry  W.  Mathers,  Dept.  M-41 

IIT  Research  Institute 

ATTN:  Irving  N.  Mindel 

Intelcom  Rad  Tech 

ATTN:  R.  L.  Mertz 
ATTN;  Leo  D.  Cotter 
AITN:  Eric  P.  Wenaas 
ATTN:  MDC 

Kaman  Sciences  Corporation 
ATTN:  John  R.  Hoffman 
ATTN:  Albert  P.  Bridges 
ATTN:  Donald  H.  Bryce 
ATTN:  W.  Foster  Rich 
ATTN:  Walter  E.  Ware 

Litton  Systems,  Inc. 

Guidance  I Control  Systems  Division 
ATTN:  R.  W.  Maughmer 
ATTN:  Val  J.  Ashby,  M.S.  67 

Lockheed  Missiles  fr  $^ace  Co.,  Inc. 

ATTN:  Gfsorge  F,  Heath,  Dept.  81-14 
ATTN:  Benjamin  T.  Kimura,  Dept.  81-14 
ATTN:  Hans  L.  Schneemann,  Dept.  81-64 
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LTV  Atrospaco  Corporation 

A rTN:  TtK'hnical  Data  Ctr. 

Martin  Marietta  Aerospace 

ATTN;  Jack  M.  Ashford.  Ml'-f)37 
A FTN:  Mona  C.  (iriffith,  Library,  MP-30 
ATTN;  William  W.  Mras,  MP-4i3 

Martin  Marietta  Corporation 

Denver  Division 

ATTN  .1.  F.  (ioodwin,  Mail  0452 
ATTN:  Paul  G.  Kase.  Mail  H203 

McDonnell  l>ouKlas  Corp<Jration 
ATTN:  Tom  EmJer 
ATTN;  Technical  Llbrar> 

McDonnell  IXiu^las  Corpc^ration 
AT7*N:  Stanley  Schneider 
ATTN:  Raymond  J.  De Battista 

McDonnell  Douglas  Corporation 

ATTN:  Technical  Library,  Cl-290/36-84 

Mission  Kesearch  Corporation 
ATTN:  WUliam  C.  Hart 

Mission  Research  Corporation 
ATTN:  J.  Roger  Hill 
ATTN:  David  K.  Merewether 

The  Mitre  Corporation 

ATTN:  M.  E.  Fitzgerald 

National  Academy  of  Sciences 

A7TN;  National  Materials  Advisory  Board  for 
R.  S.  Shane,  Nat.  Materials  Advsy 

Northrop  Corporation 

Electronic  Division 

ATTN:  Boyce  T.  Ahlport 
ATTN:  George  H.  Towner 
ATTN:  Vincent  R.  DoMartino 

Northrop  Corporation 

ATTN:  Orlie  L.  Curtis,  Jr. 

ATTN:  James  P.  Ra.vmond 
ATTN:  David  N.  Pocock 

Northrop  Corporation 

Electronic  Division 

ATTN:  Joseph  D.  Russo 

Physics  International  Company 

ATTN:  Dor.  Con.  for  John  H.  Huntington 

R 1 1)  Associates 

ATTN:  S.  Clay  Rogers 
ATTN:  I.eonard  Schlcssinger 

The  Rand  Corporation 
ATTN:  Cullen  Crain 

Raytheon  Company 

ATTN:  Ga)anan  H.  JoshI,  Radar  Sys.  Lah. 

Raytheon  Company 

ATTN:  James  R.  Weekback 
ATTN:  Harold  L.  Flescher 


RCA  Corporation 

Governnamt  it  Commercial  Systems 
Astro  Electronics  Division 

ATTN:  tVorge  J.  Hrucker 

RCA  Cor|)oralion 

Ari'N:  E.  Van  Keuren,  13-5-2 

Rockwell  International  Corporation 
ATTN:  James  E.  Bell,  HA-10 
ATTN:  fk-orgi'  C.  .Mes.senger,  FB-61 

Rockwell  International  Corporation 
Electronics  Operations 

ATTN:  Mildred  A.  HI  air 
ATTN:  Alan  A.  Langenfeld 
ATTN:  Dennis  Sutherland 

.Sanders  AssociaU-s,  Ine. 

ATTN:  Moe  L.  Aitel,  NCA,  1-3230 

Science  Applications,  Inc. 

AITN:  Frederick  M.  Tesche 

Science  Applications,  Inc. 

ATTN:  William  L.  Chadsey 

Science  Applications,  Inc. 

ATTN:  J.  Kot»-rt  BeysUr 
ATTN:  Larry  Scott 

Science  Applications,  Inc, 

Huntsville  Division 

ATTN:  Noel  R.  Byrn 

Simulation  Physics,  Inc. 

ATTN:  John  R.  Cglum 

The  Singer  Company 

ATTN:  Irwin  Cioldman,  Eng,  Management 

Sperry  Flight  sysu*ms  Division 
Sperry  Rand  Corporation 

ATTN:  D,  Andrew  Schow 

Sperry  Rand  Corporation 
Sperry  Division 

ATTN:  Paul  Marraffino 

Stanford  Research  Institute 
ATTN:  Philip  J.  Dolan 
ATTN:  Arthur  Leo  Whitson 

Sundstrand  Corporation 

ATTN:  Curtis  B.  White 

.Systron-Donm-r  Corporation 
ATTN:  Gordon  B,  Ik’an 

Texas  Instruments,  Ine. 

ATTN:  Gary  F.  Hanson 

ATTN:  Donald  J.  Manus,  M.S.  72 

Texas  Tech  University 

ATTN:  Travis  L.  Simpson 

TRW  Systems  Group 

ATTN:  John  E.  Dahnke 
ATTN:  H.  S.  Jensen 
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TRW  Group 

ATTN:  A.  M.  LU'lmchuti,  R1-11B2 
ATTN:  Richard  H.  KinKaland,  Rl-215-t 
ATTN;  A.  A.  Wittelcg,  Rl-1120 
ATTN:  Aaron  H.  Narcvaky,  R1-2M4 
ATTN:  Benjamin  SusiihoUa 
ATTN:  LUlian  D.  Singlclary,  Rl-1070 
ATTN:  Jerry  1.  Lubell 

United  TechnoloRles  Corporation 
Hamilton  Standard  Division 

ATTN:  Raymond  G.  Giguerc 


Victor  A.  J.  Van  Lint,  Consultant 
Mission  Research  Corporation 
ATTN:  V.  A.  J.  Van  Lint 

Westinghouse  Electric  Corporation 

ATTN:  Henry  P.  Kalapaca,  M.S.  3525 


